Local file access with JavaScript

Question

Is there local file manipulation that's been done with JavaScript? I'm looking for a solution that can be accomplished with no install footprint like requiring Adobe AIR.

Specifically, I'd like to read the contents from a file and write those contents to another file. At this point I'm not worried about gaining permissions and am just assuming I already have full permissions to these files.

Solution 1

If the user selects a file via <input type="file">, you can read and process that file using the File API.

Reading or writing arbitrary files is not allowed by design. It's a violation of the sandbox. From Wikipedia -> Javascript -> Security:

JavaScript and the DOM provide the potential for malicious authors to deliver scripts to run on a client computer via the web. Browser authors contain this risk using two restrictions. First, scripts run in a sandbox in which they can only perform web-related actions, not general-purpose programming tasks like creating files.

2016 UPDATE: Accessing the filesystem directly is possible via the Filesystem API, which is only supported by Chrome and Opera and may end up not being implemented by other browsers (with the exception of Edge). For details see Kevin's answer.

Solution 2

Just an update of the HTML5 features is in http://www.html5rocks.com/en/tutorials/file/dndfiles/. This excellent article will explain in detail the local file access in JavaScript. Summary from the mentioned article:

The specification provides several interfaces for accessing files from a 'local' filesystem:

1. File - an individual file; provides readonly information such as name, file size, MIME type, and a reference to the file handle.
2. FileList - an array-like sequence of File objects. (Think <input type="file" multiple> or dragging a directory of files from the desktop).
3. Blob - Allows for slicing a file into byte ranges.

See Paul D. Waite's comment below.

Solution 3

UPDATE This feature is removed since Firefox 17 (see https://bugzilla.mozilla.org/show_bug.cgi?id=546848).

---

On Firefox you (the programmer) can do this from within a JavaScript file:

netscape.security.PrivilegeManager.enablePrivilege("UniversalBrowserRead");
netscape.security.PrivilegeManager.enablePrivilege("UniversalBrowserWrite");

and you (the browser user) will be prompted to allow access. (for Firefox you just need to do this once every time the browser is started)

If the browser user is someone else, they have to grant permission.

Solution 4

As previously mentioned, the FileSystem and File APIs, along with the FileWriter API, can be used to read and write files from the context of a browser tab/window to a client machine.

There are several things pertaining to the FileSystem and FileWriter APIs which you should be aware of, some of which were mentioned, but are worth repeating:

• Implementations of the APIs currently exist only in Chromium-based browsers (Chrome & Opera)
• Both of the APIs were taken off of the W3C standards track on April 24, 2014, and as of now are proprietary
• Removal of the (now proprietary) APIs from implementing browsers in the future is a possibility
• A sandbox (a location on disk outside of which files can produce no effect) is used to store the files created with the APIs
• A virtual file system (a directory structure which does not necessarily exist on disk in the same form that it does when accessed from within the browser) is used represent the files created with the APIs

Here are simple examples of how the APIs are used, directly and indirectly, in tandem to do these things:

BakedGoods*

Write file:

bakedGoods.set({
    data: [{key: "testFile", value: "Hello world!", dataFormat: "text/plain"}],
    storageTypes: ["fileSystem"],
    options: {fileSystem:{storageType: Window.PERSISTENT}},
    complete: function(byStorageTypeStoredItemRangeDataObj, byStorageTypeErrorObj){}
});

Read file:

bakedGoods.get({
        data: ["testFile"],
        storageTypes: ["fileSystem"],
        options: {fileSystem:{storageType: Window.PERSISTENT}},
        complete: function(resultDataObj, byStorageTypeErrorObj){}
});

Using the raw File, FileWriter, and FileSystem APIs

Write file:

function onQuotaRequestSuccess(grantedQuota)
{

    function saveFile(directoryEntry)
    {

        function createFileWriter(fileEntry)
        {

            function write(fileWriter)
            {
                var dataBlob = new Blob(["Hello world!"], {type: "text/plain"});
                fileWriter.write(dataBlob);              
            }

            fileEntry.createWriter(write);
        }

        directoryEntry.getFile(
            "testFile", 
            {create: true, exclusive: true},
            createFileWriter
        );
    }

    requestFileSystem(Window.PERSISTENT, grantedQuota, saveFile);
}

var desiredQuota = 1024 * 1024 * 1024;
var quotaManagementObj = navigator.webkitPersistentStorage;
quotaManagementObj.requestQuota(desiredQuota, onQuotaRequestSuccess);

Read file:

function onQuotaRequestSuccess(grantedQuota)
{

    function getfile(directoryEntry)
    {

        function readFile(fileEntry)
        {

            function read(file)
            {
                var fileReader = new FileReader();

                fileReader.onload = function(){var fileData = fileReader.result};
                fileReader.readAsText(file);             
            }

            fileEntry.file(read);
        }

        directoryEntry.getFile(
            "testFile", 
            {create: false},
            readFile
        );
    }

    requestFileSystem(Window.PERSISTENT, grantedQuota, getFile);
}

var desiredQuota = 1024 * 1024 * 1024;
var quotaManagementObj = navigator.webkitPersistentStorage;
quotaManagementObj.requestQuota(desiredQuota, onQuotaRequestSuccess);

Though the FileSystem and FileWriter APIs are no longer on the standards track, their use can be justified in some cases, in my opinion, because:

• Renewed interest from the un-implementing browser vendors may place them right back on it
• Market penetration of implementing (Chromium-based) browsers is high
• Google (the main contributer to Chromium) has not given and end-of-life date to the APIs

Whether "some cases" encompasses your own, however, is for you to decide.

*BakedGoods is maintained by none other than this guy right here :)

Solution 5

NW.js allows you to create desktop applications using Javascript without all the security restrictions usually placed on the browser. So you can run executables with a function, or create/edit/read/write/delete files. You can access the hardware, such as current CPU usage or total ram in use, etc.

You can create a windows, linux, or mac desktop application with it that doesn't require any installation.

• http://nwjs.io

View more solutions

Comments

[Ciro Santilli OurBigBook.com]

chrome XHR specific: stackoverflow.com/questions/4819060/…

[Jared]

I'd like the solution to be os-independent (at least between windows and mac), so the windows script host doesn't satisfy it, unless there is a comparable solution for the mac platform

[Admin]

Damn. This is stupid, of course. Javascript is supposedly an application-agnostic scripting language. Not every application is a web browser. I came here because I'm interested in scripting Photoshop, for instance. Even if some applications don't provide file access classes, it makes sense to standardize them for those applications where they are appropriate - a standard but optional feature, so experience from one app is transferable even if not universally applicable. What I learn in Photoshop won't be portable even to other Javascript hosts that allow file access.

[Admin]

Javascript the language and do whatever the hosting environment allows it to do. SpiderMonkey can do anything any other language can do. Javascript in the Browser is sandboxed.

[james.garriss]

This answer might have been correct 3 years ago, but it's certainly not correct any longer. See @Horst Walter's answer on HTML5. Or go here: html5rocks.com/en/tutorials/file/dndfiles

[Esailija]

This gives an error that it is deprecated and you can only do this in an extension, not website javascript

[Makan Tayebi]

as this link shows, this feature has been removed in later firefox versions. support.mozilla.org/en-US/questions/944433

[Jason S]

oh, that sucks. I get security and all that, but we need a way of granting trust to run our own javascript files locally.

[Makan Tayebi]

sure. and I have not found another way to do this yet.

[original_username]

@james.garriss Yeah, actually it wasn't super correct three years ago either. This page taught me how to read/write with Firefox back in 2003 web.archive.org/web/20031229011919/http://www.captain.at/… (bulit for XUL but available in the browser with XpCom) and Microsoft had node.js-style javscript shell scripting in the 1990s (and FileIO available in the browser with ActiveX)

[Pacerier]

It's not exactly a true filesystem like what we have using Java or Flash plugin. For example, we can't list the files on the user's Desktop unless he first selects them himself.

[Joe Dargie]

Looks like these APIs are being abandoned: see w3.org/TR/file-writer-api and html5rocks.com/en/tutorials/file/filesystem

[jpaugh]

Please update the answer to show that it is deprecated. Thanks.

[bbsimonbb]

Careful there, given the W3C's form for snatching away useful technology. The filesystem api, only implemented in chrome, is not going forward. The file api, has universal support, is accepted as a w3c working draft and we can no longer imagine life without it. Of course we're still in a browser, and we have to wait til the user brings us the file, but this dramatically extends the reach of web apps and is not going away anytime soon.

[Admin]

@Ian Campbell - Try reading the whole comment before replying to it. If you did that you'd know I know about filesystem access in the Photoshop variant of Javascript, but I also know that it's e.g. completely different to filesystem access in the old Macromedia Flash MX2004 variant of Javascript. Of course since Adobe bought Macromedia, they've obviously standardized, but what about other vendors? As I said, "Even if some applications don't provide file access classes, it makes sense to standardize them for those applications where they are appropriate - a standard but optional feature..."

[Admin]

@Ian Campbell - That may have happened by now, though - I haven't kept up with the changes in Javascript / ECMAscript.

[Phillip Senn]

FSO.js is not currently supported by IE, Mozilla, or Safari.

[Dan Dascalescu]

@james.garriss: I've updated and corrected the answer, because both the question asker and the answerer haven't been on SO in years, and this is the accepted answer.

[Anderson Green]

It's also possible to access local files using Electron, which is a similar framework for JavaScript desktop applications.

[Sebi2020]

The file API is not only supported by Chrome & Opera. And the File API is not removed from the specification. It would be helpful to clearify which "two APIs" you mean if you say they are removed. I think you're talking about the FileWriter and the FileSystem API.