This specification provides an API for representing file objects in web applications, as well as programmatically selecting them and accessing their data. This includes:
- A FileList interface, which represents an array of individually selected files from the underlying system. The user interface for selection can be invoked via <input type="file">. i.e. when the input element is in the File Upload state [HTML ] .
- A Blob interface, which represents immutable raw binary data, and allows access to ranges of bytes within the Blob object as a separate Blob .
- A File interface, which includes readonly informational attributes about a file such as its name and the date of the last modification (on disk) of the file.
- A FileReader interface, which provides methods to read a File or a Blob. and an event model to obtain the results of these reads.
- A URL scheme for use with binary data such as files, so that they can be referenced within web applications.
Additionally, this specification defines objects to be used within threaded web applications for the synchronous reading of files.
The section on Requirements and Use Cases [REQ ] covers the motivation behind this specification.
This API is designed to be used in conjunction with other APIs and elements on the web platform, notably: XMLHttpRequest (e.g. with an overloaded send() method for File or Blob arguments), postMessage. DataTransfer (part of the drag and drop API defined in [HTML ]) and Web Workers. Additionally, it should be possible to programmatically obtain a list of files from the input element when it is in the File Upload state [HTML ]. These kinds of behaviors are defined in the appropriate affiliated specifications.
Status of this Document
This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.
If you have comments for this spec, please send them to public-webapps@w3.org with a Subject: prefix of [FileAPI]. See Bugzilla for this specification's open bugs.
This document was published by the Web Applications Working Group as a Working Draft. This document is intended to become a W3C Recommendation. If you wish to make comments regarding this document, please send them to public-webapps@w3.org (subscribe. archives ). All comments are welcome.
Publication as a Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.
This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.
This document is governed by the 1 August 2014 W3C Process Document.
Table of Contents
1. Introduction
This section is informative.
Web applications should have the ability to manipulate as wide as possible a range of user input, including files that a user may wish to upload to a remote server or manipulate inside a rich web application. This specification defines the basic representations for files, lists of files, errors raised by access to files, and programmatic ways to read files. Additionally, this specification also defines an interface that represents "raw data" which can be asynchronously processed on the main thread of conforming user agents. The interfaces and API defined in this specification can be used with other interfaces and APIs exposed to the web platform.
The File interface represents file data typically obtained from the underlying (OS) file system, and the Blob interface ("Binary Large Object" - a name originally introduced to web APIs in Google Gears ) represents immutable raw data. File or Blob reads should happen asynchronously on the main thread, with an optional synchronous API used within threaded web applications. An asynchronous API for reading files prevents blocking and UI "freezing" on a user agent's main thread. This specification defines an asynchronous API based on an event model to read and access a File or Blob 's data. A FileReader object provides asynchronous read methods to access that file's data through event handler attributes and the firing of events. The use of events and event handlers allows separate code blocks the ability to monitor the progress of the read (which is particularly useful for remote drives or mounted drives, where file access performance may vary from local drives) and error conditions that may arise during reading of a file. An example will be illustrative.
In the example below, different code blocks handle progress, error, and success conditions.
2. Conformance
Everything in this specification is normative except for examples and sections marked as being informative.
The keywords “ MUST â€, “ MUST NOT â€, “ REQUIRED â€, “ SHALL â€, “ SHALL NOT â€, “ RECOMMENDED â€, “ MAY †and “ OPTIONAL †in this document are to be interpreted as described in Key words for use in RFCs to Indicate Requirement Levels [RFC2119].
The following conformance classes are defined by this specification:
conforming user agent
A user agent is considered to be a conforming user agent if it satisfies all of the MUST -, REQUIRED - and SHALL -level criteria in this specification that apply to implementations. This specification uses both the terms "conforming user agent" and "user agent" to refer to this product class.
User agents may implement algorithms in this specifications in any way desired, so long as the end result is indistinguishable from the result that would be obtained from the specification's algorithms.
User agents that use ECMAScript to implement the APIs defined in this specification must implement them in a manner consistent with the ECMAScript Bindings defined in the Web IDL specification [WEBIDL ] as this specification uses that specification and terminology.
3. Dependencies
This specification relies on underlying specifications.
A conforming user agent must support at least the subset of the functionality defined in DOM4 that this specification relies upon; in particular, it must support EventTarget. [DOM4 ]
A conforming user agent must support the Progress Events specification. Data access on read operations is enabled via Progress Events.[ProgressEvents ]
A conforming user agent must support at least the subset of the functionality defined in HTML that this specification relies upon; in particular, it must support event loops and event handler attributes. [HTML ]
A conforming user agent must also be a conforming implementation of the IDL fragments in this specification, as described in the Web IDL specification. [WebIDL ]
Parts of this specification rely on the Web Workers specification; for those parts of this specification, the Web Workers specification is a normative dependency. [Workers ]
4. Terminology
The terms and algorithms document. unloading document cleanup steps. event handler attributes. event handler event type. effective script origin. incumbent settings object. event loops. task. task source. URL. global script cleanup jobs list. global script cleanup. queue a task. UTF-8. UTF-16. structured clone. collect a sequence of characters and converting a string to ASCII lowercase are as defined by the HTML specification [HTML ].
The terms origin and same origin are as defined by the Web Origin Concept specification [ORIGIN ].
When this specification says to terminate an algorithm the user agent must terminate the algorithm after finishing the step it is on, and return from it. Asynchronous read methods defined in this specification may return before the algorithm in question is terminated, and can be terminated by an abort() call.
The term throw in this specification, as it pertains to exceptions, is used as defined in the DOM4 specification [DOM4 ].
The term byte in this specification is used as defined in the Encoding Specification [Encoding Specification ].
The term chunk in this specification is used as defined in the Streams Specification [Streams Specification .]
The term context object in this specification is used as defined in the DOM4 specification [DOM4 ].
The terms URL. relative URL. base URL. URL parser. basic URL Parser. scheme. host. relative scheme. scheme data. and fragment are as defined by the WHATWG URL Specification [URL ].
The terms request. response. body and cross-origin request are as defined in the WHATWG Fetch Specification [Fetch Specification ].
The term Unix Epoch is used in this specification to refer to the time 00:00:00 UTC on January 1 1970 (or 1970-01-01T00:00:00Z ISO 8601); this is the same time that is conceptually "0" in ECMA-262 [ECMA-262 ].
The algorithms and steps in this specification use the following mathematical operations:
max(a,b) returns the maximum of a and b, and is always performed on integers as they are defined in WebIDL [WebIDL ]; in the case of max(6,4) the result is 6. This operation is also defined in ECMAScript [ECMA-262 ].
min(a,b) returns the minimum of a and b, and is always performed on integers as they are defined in WebIDL [WebIDL ]; in the case of min(6,4) the result is 4. This operation is also defined in ECMAScript [ECMA-262 ].
Mathematical comparisons such as < (less than), ≤ (less than or equal to) and > (greater than) are as in ECMAScript [ECMA-262 ].
5. The Blob Interface and Binary Data
A Blob object refers to a byte sequence, and has a size attribute which is the total number of bytes in the byte sequence, and a type attribute, which is an ASCII-encoded string in lower case representing the media type of the byte sequence.
A Blob must have a readability state. which is one of OPENED or CLOSED. A Blob that refers to a byte sequence, including one of 0 bytes, is said to be in the OPENED readability state. A Blob is said to be closed if its close method has been called. A Blob that is closed is said to be in the CLOSED readability state .
Each Blob must have an internal snapshot state. which must be initially set to the state of the underlying storage, if any such underlying storage exists, and must be preserved through structured clone. Further normative definition of snapshot state can be found for files.
5.1. Constructors
The Blob() constructor can be invoked with zero or more parameters. When the Blob() constructor is invoked, user agents must run the following Blob constructor steps :
If invoked with zero parameters, return a new Blob object with its readability state set to OPENED. consisting of 0 bytes, with size set to 0, and with type set to the empty string.
Otherwise, the constructor is invoked with a blobParts sequence. Let a be that sequence.
Let bytes be an empty sequence of bytes.
Let length be a 's length. For 0 ≤ i < length. repeat the following steps:
Let element be the i th element of a .
If element is a DOMString. run the following substeps:
Let s be the result of converting element to a sequence of Unicode characters [Unicode ] using the algorithm for doing so in WebIDL [WebIDL ].
Encode s as UTF-8 and append the resulting bytes to bytes .
The algorithm from WebIDL [WebIDL ] replaces unmatched surrogates in an invalid UTF-16 string with U+FFFD replacement characters. Scenarios exist when the Blob constructor may result in some data loss due to lost or scrambled character sequences.
If element is an ArrayBufferView [TypedArrays ], convert it to a sequence of byteLength bytes from the underlying ArrayBuffer. starting at the byteOffset of the ArrayBufferView [TypedArrays ], and append those bytes to bytes .
If element is an ArrayBuffer [TypedArrays ], convert it to a sequence of byteLength bytes, and append those bytes to bytes .
If element is a Blob. append the bytes it represents to bytes. The type of the Blob array element is ignored.
If the type member of the optional options argument is provided and is not the empty string, run the following sub-steps:
- Let t be the type dictionary member. If t contains any characters outside the range U+0020 to U+007E, then set t to the empty string and return from these substeps.
- Convert every character in t to lowercase using the "converting a string to ASCII lowercase " algorithm [WebIDL ].
Return a Blob object with its readability state set to OPENED. referring to bytes as its associated byte sequence, with its size set to the length of bytes. and its type set to the value of t from the substeps above.
The type t of a Blob is considered a parsable MIME type if the ASCII-encoded string representing the Blob object's type, when converted to a byte sequence, does not return undefined for the parse MIME type algorithm [MIMESNIFF ].
5.1.1. Constructor Parameters
The Blob() constructor can be invoked with the parameters below:
A blobParts sequence which takes any number of the following types of elements, and in any order:- type. the ASCII-encoded string in lower case representing the media type of the Blob. Normative conditions for this member are provided in the Blob constructor steps.
Examples of constructor usage follow.
5.2. Attributes
Returns the size of the byte sequence in number of bytes. On getting, conforming user agents must return the total number of bytes that can be read by a FileReader or FileReaderSync object, or 0 if the Blob has no bytes to be read. If the Blob has a readability state of CLOSED then size must return 0.
The ASCII-encoded string in lower case representing the media type of the Blob. On getting, user agents must return the type of a Blob as an ASCII-encoded string in lower case, such that when it is converted to a byte sequence, it is a parsable MIME type [MIMESNIFF ], or the empty string -- 0 bytes -- if the type cannot be determined. The type attribute can be set by the web application itself through constructor invocation and through the slice call; in these cases, further normative conditions for this attribute are in the Blob constructor steps. the File Constructor steps. and the slice method algorithm respectively. User agents can also determine the type of a Blob. especially if the byte sequence is from an on-disk file; in this case, further normative conditions are in the file type guidelines..
The boolean value that indicates whether the Blob is in the CLOSED readability state. On getting, user agents must return false if the Blob is in the OPENED readability state. and true if the Blob is in the CLOSED readability state as a result of the close method being called.
5.3. Methods and Parameters
5.3.1. The slice method
The slice method returns a new Blob object with bytes ranging from the optional start parameter upto but not including the optional end parameter, and with a type attribute that is the value of the optional contentType parameter. It must act as follows :
Let O be the Blob context object on which the slice method is being called.
The optional start parameter is a value for the start point of a slice call, and must be treated as a byte-order position, with the zeroth position representing the first byte. User agents must process slice with start normalized according to the following:
If the optional start parameter is not used as a parameter when making this call, let relativeStart be 0.
If start is negative, let relativeStart be max(( size + start ), 0) .
Else, let relativeStart be min(start, size) .
The optional end parameter is a value for the end point of a slice call. User agents must process slice with end normalized according to the following:
If the optional end parameter is not used as a parameter when making this call, let relativeEnd be size .
If end is negative, let relativeEnd be max((size + end), 0)
Else, let relativeEnd be min(end, size)
The optional contentType parameter is used to set the ASCII-encoded string in lower case representing the media type of the Blob. User agents must process the slice with contentType normalized according to the following:
If the contentType parameter is not provided, let relativeContentType be set to the empty string .
Else let relativeContentType be set to contentType and run the substeps below:
- If relativeContentType contains any characters outside the range of U+0020 to U+007E, then set relativeContentType to the empty string and return from these substeps.
- Convert every character in relativeContentType to lower case using the "Converting a string to ASCII lowercase " algorithm.
Let span be max((relativeEnd - relativeStart), 0) .
Return a new Blob object S with the following characteristics:
The readability state of the context object is retained by the Blob object returned by the slice call; this has implications on whether the returned Blob is actually usable for read operation s or as a Blob URL .
S refers to span consecutive byte s from O. beginning with the byte at byte-order position relativeStart .
The type t of a Blob is considered a parsable MIME type if the ASCII-encoded string representing the Blob object's type, when converted to a byte sequence, does not return undefined for the parse MIME type algorithm [MIMESNIFF ].
The examples below illustrate the different types of slice calls possible. Since the File interface inherits from the Blob interface, examples are based on the use of the File interface.
6. The File Interface
A File object is a Blob object with a name attribute, which is a string; it can be created within the web application via a constructor, or is a reference to a byte sequence from a file from the underlying (OS) file system.
If a File object is a reference to a byte sequence originating from a file on disk, then its snapshot state should be set to the state of the file on disk at the time the File object is created.
This is a non-trivial requirement to implement for user agents, and is thus not a must but a should [RFC2119 ]. User agents should endeavor to have a File object's snapshot state set to the state of the underlying storage on disk at the time the reference is taken. If the file is modified on disk following the time a reference has been taken, the File 's snapshot state will differ from the state of the underlying storage. User agents may use modification time stamps and other mechanisms to maintain snapshot state. but this is left as an implementation detail.
When a File object refers to a file on disk, user agents must return the type of that file, and must follow the file type guidelines below:
User agents must return the type as an ASCII-encoded string in lower case, such that when it is converted to a corresponding byte sequence, it is a parsable MIME type [MIMESNIFF ], or the empty string -- 0 bytes -- if the type cannot be determined.
When the file is of type text/plain user agents must NOT append a charset parameter to the dictionary of parameters portion of the media type [MIMESNIFF ].
User agents must not attempt heuristic determination of encoding, including statistical methods.
6.1 Constructor
The File constructor is invoked with two or three parameters, depending on whether the optional dictionary parameter is used. When the File() constructor is invoked, user agents must run the following File constructor steps :
- Let a be the fileBits sequence argument. Let bytes be an empty sequence of bytes. Let length be a 's length. For 0 ≤ i < length. repeat the following steps:
- Let element be the i 'th element of a .
- If element is a DOMString. run the following substeps:
Let s be the result of converting element to a sequence of Unicode characters [Unicode ] using the algorithm for doing so in WebIDL [WebIDL ].
Encode s as UTF-8 and append the resulting bytes to bytes .
The algorithm from WebIDL [WebIDL ] replaces unmatched surrogates in an invalid UTF-16 string with U+FFFD replacement characters. Scenarios exist when the Blob constructor may result in some data loss due to lost or scrambled character sequences.
- If element is an ArrayBufferView [TypedArrays ], convert it to a sequence of byteLength bytes from the underlying ArrayBuffer, starting at the byteOffset of the ArrayBufferView [TypedArrays ], and append those bytes to bytes .
-
If element is an ArrayBuffer [TypedArrays ], convert it to a sequence of byteLength bytes, and append those bytes to bytes .
If element is a Blob. append the bytes it represents to bytes. The type of the Blob argument must be ignored.
- Let n be a new string of the same size as the fileName argument to the constructor. Copy every character from fileName to n. replacing any "/" character (U+002F SOLIDUS) with a ":" (U+003A COLON).
Underlying OS filesystems use differing conventions for file name; with constructed files, mandating UTF-16 lessens ambiquity when file names are converted to byte sequences.
- If the optional FilePropertyBag dictionary argument is used, then run the following substeps:
- If the type member is provided and is not the empty string, let t be set to the type dictionary member. If t contains any characters outside the range U+0020 to U+007E, then set t to the empty string and return from these substeps.
- Convert every character in t to lowercase using the "converting a string to ASCII lowercase algorithm " [WebIDL ].
- If the lastModified member is provided, let d be set to the lastModified dictionary member. If it is not provided, set d to the current date and time represented as the number of milliseconds since the Unix Epoch (which is the equivalent of Date.now() [ECMA-262 ]).
Since ECMA-262 Date objects convert to long long values representing the number of milliseconds since the Unix Epoch. the lastModified member could be a Date object [ECMA-262 ].
- F has a readability state of OPENED .
- F refers to the bytes byte sequence.
- F.size is set to the number of total bytes in bytes .
- F.name is set to n .
- F.type is set to t.
The type t of a File is considered a parsable MIME type if the ASCII-encoded string representing the File object's type, when converted to a byte sequence, does not return undefined for the parse MIME type algorithm [MIMESNIFF ].
6.1.1 Constructor Parameters
The File() constructor can be invoked with the parameters below:
A fileBits sequence which takes any number of the following elements, and in any order:Blob elements, which includes File elements.
A name parameter
A DOMString [WebIDL ] parameter representing the name of the file; normative conditions for this constructor parameter can be found in the File constructor steps .
which takes the following members:
An optional type member; the ASCII-encoded string in lower case representing the media type of the File. Normative conditions for this member are provided in the File constructor steps .
An optional lastModified member, which must be a long long ; normative conditions for this member are provided in the File constructor steps .
6.2. Attributes
The name of the file; on getting, this must return the name of the file as a string. There are numerous file name variations and conventions used by different underlying OS file systems; this is merely the name of the file, without path information. On getting, if user agents cannot make this information available, they must return the empty string. If a File object is created using a constructor, further normative conditions for this attribute are found in the file constructor steps .
The last modified date of the file. On getting, if user agents can make this information available, this must return a long long set to the time the file was last modified as the number of milliseconds since the Unix Epoch. If the last modification date and time are not known, the attribute must return the current date and time as a long long representing the number of milliseconds since the Unix Epoch ; this is equivalent to Date.now() [ECMA-262 ]. If a File object is created using a constructor, further normative conditions for this attribute are found in the file constructor steps.
The File interface is available on objects that expose an attribute of type FileList ; these objects are defined in HTML [HTML ]. The File interface, which inherits from Blob. is immutable, and thus represents file data that can be read into memory at the time a read operation is initiated. User agents must process reads on files that no longer exist at the time of read as errors. throwing a NotFoundError exception if using a FileReaderSync on a Web Worker [Workers ] or firing an error event with the error attribute returning a NotFoundError DOMError .
In the examples below, metadata from a file object is displayed meaningfully, and a file object is created with a name and a last modified date.
7. The FileList Interface
The FileList interface should be considered "at risk" since the general trend on the Web Platform is to replace such interfaces with the Array platform object in ECMAScript [ECMA-262 ]. In particular, this means syntax of the sort filelist.item(0) is at risk; most other programmatic use of FileList is unlikely to be affected by the eventual migration to an Array type.
This interface is a list of File objects.
Sample usage typically involves DOM access to the <input type="file"> element within a form, and then accessing selected files.
7.1. Attributes
must return the number of files in the FileList object. If there are no files, this attribute must return 0.
7.2. Methods and Parameters
must return the indexth File object in the FileList. If there is no indexth File object in the FileList. then this method must return null .
index must be treated by user agents as value for the position of a File object in the FileList. with 0 representing the first file. Supported property indices [WebIDL ] are the numbers in the range zero to one less than the number of File objects represented by the FileList object. If there are no such File objects, then there are no supported property indices [WebIDL ].
The HTMLInputElement interface [HTML ] has a readonly attribute of type FileList. which is what is being accessed in the above example. Other interfaces with a readonly attribute of type FileList include the DataTransfer interface [HTML ].
8. Reading Data
8.1 The Read Operation
The algorithm below defines a read operation. which takes a Blob and a synchronous flag as input, and reads byte s into a byte stream which is returned as the result of the read operation. or else fails along with a failure reason. Methods in this specification invoke the read operation with the synchronous flag either set or unset.
The synchronous flag determines if a read operation is synchronous or asynchronous, and is unset by default. Methods may set it. If it is set, the read operation takes place synchronously. Otherwise, it takes place asynchronously.
To perform a read operation on a Blob and the synchronous flag. run the following steps:
Let s be a a new body. b be the Blob to be read from, and bytes initially set to an empty byte sequence. Set the length on s to the size of b. While there are still bytes to be read in b perform the following substeps:
The algorithm assumes that invoking methods have checked for readability state. A Blob in the CLOSED state must not have a read operation called on it.
If the synchronous flag is set, follow the steps below:
Let bytes be the byte sequence that results from reading a chunk from b. If an error occurs reading a chunk from b. return s with the error flag set, along with a failure reason. and terminate this algorithm.
Along with returning failure, the synchronous part of this algorithm must return the failure reason that occurred for throwing an exception by synchronous methods that invoke this algorithm with the synchronous flag set.
If there are no errors, push bytes to s. and increment s 's transmitted [Fetch ] by the number of bytes in bytes. Reset bytes to the empty byte sequence and continue reading chunk s as above.
When all the bytes of b have been read into s. return s and terminate this algorithm .
Otherwise, the synchronous flag is unset. Return s and process the rest of this algorithm asynchronously.
Let bytes be the byte sequence that results from reading a chunk from b. If an error occurs reading a chunk from b. set the error flag on s. and terminate this algorithm with a failure reason .
The asynchronous part of this algorithm must signal the failure reason that occurred for asynchronous error reporting by methods expecting s and which invoke this algorithm with the synchronous flag unset.
If no error occurs, push bytes to s. and increment s 's transmitted [Fetch ] by the number of bytes in bytes. Reset bytes to the empty byte sequence and continue reading chunk s as above.
To perform an annotated task read operation on a Blob b. perform the steps below:
Perform a read operation on b with the synchronous flag unset, along with the additional steps below.
If the read operation terminates with a failure reason. queue a task to process read error with the failure reason and terminate this algorithm.
When the first chunk is being pushed to the body s during the read operation. queue a task to process read .
Once the body s from the read operation has at least one chunk read into it, or there are no chunk s left to read from b. queue a task to process read data. Keep queuing tasks to process read data for every chunk read or every 50ms, whichever is least frequent .
When all of the chunk s from b are read into the body s from the read operation. queue a task to process read EOF .
8.2. The File Reading Task Source
This specification defines a new generic task source called the file reading task source. which is used for all tasks that are queued in this specification to read byte sequences associated with Blob and File objects. It is to be used for features that trigger in response to asynchronously reading binary data.
8.3 The FileReader API
8.3.1. Constructors
When the FileReader() constructor is invoked, the user agent must return a new FileReader object.
In environments where the global object is represented by a Window or a WorkerGlobalScope object, the FileReader constructor must be available.
8.3.2. Event Handler Attributes
The following are the event handler attributes (and their corresponding event handler event types ) that user agents must support on FileReader as DOM attributes:
8.3.3. FileReader States
The FileReader object can be in one of 3 states. The readyState attribute, on getting, must return the current state, which must be one of the following values:
EMPTY (numeric value 0)
The FileReader object has been constructed, and there are no pending reads. None of the read methods have been called. This is the default state of a newly minted FileReader object, until one of the read methods have been called on it.
LOADING (numeric value 1)
A File or Blob is being read. One of the read methods is being processed, and no error has occurred during the read.
DONE (numeric value 2)
The entire File or Blob has been read into memory, OR a file error occurred during read. OR the read was aborted using abort(). The FileReader is no longer reading a File or Blob. If readyState is set to DONE it means at least one of the read methods have been called on this FileReader .
8.3.4. Reading a File or Blob
Multiple Reads
The FileReader interface makes available three asynchronous read methods - readAsArrayBuffer. readAsText. and readAsDataURL. which read files into memory. If multiple concurrent read methods are called on the same FileReader object, user agents must throw an InvalidStateError [DOM4 ] on any of the read methods that occur when readyState = LOADING.
8.3.4.1. The result attribute
On getting, the result attribute returns a Blob 's data as a DOMString. or as an ArrayBuffer [TypedArrays ], or null. depending on the read method that has been called on the FileReader. and any errors that may have occurred. The list below is normative for the result attribute and is the conformance criteria for this attribute:
On getting, if the readyState is EMPTY (no read method has been called) then the result attribute must return null .
On getting, if an error in reading the File or Blob has occurred (using any read method ), then the result attribute must return null .
On getting, if the readAsDataURL read method is used, the result attribute must return a DOMString that is a Data URL [DataURL ] encoding of the File or Blob 's data.
On getting, if the readAsText read method is called and no error in reading the File or Blob has occurred, then the result attribute must return a string representing the File or Blob 's data as a text string, and should decode the string into memory in the format specified by the encoding determination as a DOMString.
On getting, if the readAsArrayBuffer read method is called and no error in reading the File or Blob has occurred, then the result attribute must return an ArrayBuffer [TypedArrays ] object.
8.3.4.2. The readAsDataURL(blob) method
When the readAsDataURL(blob) method is called, the user agent must run the steps below.
Set the result attribute to the body returned by the read operation as a DataURL [DataURL ]; on getting, the result attribute returns the blob as a Data URL [DataURL ].
Use the blob 's type attribute as part of the Data URL if it is available in keeping with the Data URL specification [DataURL ].
If the type attribute is not available on the blob return a Data URL without a media-type. [DataURL ].
Data URLs that do not have media-types [RFC2046 ] must be treated as plain text by conforming user agents. [DataURL ].
8.3.4.3. The readAsText(blob, label) method
The readAsText() method can be called with an optional parameter, label. which is a DOMString argument that represents the label of an encoding [Encoding Specification ]; if provided, it must be used as part of the encoding determination used when processing this method call.
When the readAsText(blob, label) method is called (the label argument is optional), the user agent must run the steps below.
If readyState = LOADING throw an InvalidStateError [DOM4 ] and terminate these steps.