Dropzone 6 for JavaScript file uploads: a review of the enyo/dropzone library

The problem Dropzone solves for JavaScript file uploads

A plain HTML file input gives you a button and a filename. Everything a user expects from a modern upload, the drop target, the thumbnail, the progress bar, the retry, has to be written by hand. Dropzone exists to cover that gap: the README describes it as "a JavaScript library that turns any HTML element into a dropzone", with previews, progress and the XHR upload handled for you.

The audience is front-end developers who already have an upload endpoint and want the browser side done. Dropzone does not store files, does not run a server, and does not decide what your backend accepts. It posts the file to whatever url you give it. That boundary is the useful part: you keep your own API and Dropzone handles the interaction layer.

The library is written in TypeScript and ships its own types, so there is no separate @types package. That matters more than it sounds. The README states that @types/dropzone stopped at 5.7.9 and describes the v5 API, and that you should remove it if you have it installed.

How Dropzone handles drag, preview and XHR upload

The mechanism is event-driven. You construct a Dropzone instance against a selector and an options object, and the library binds drag-and-drop listeners to that element. When a file lands, Dropzone creates a file object and emits events you can subscribe to with dropzone.on(...).

The README's TypeScript example shows the shape of that object: a listener on "addedfile" receives a file whose name is available as file.name and whose upload identifier is file.upload.uuid. That uuid is worth noticing. It is the handle for a specific upload attempt, which is what lets a UI track one file through progress, success and error without keeping parallel state of its own.

Previews come from a callback rather than a fixed renderer. The feature list says you register thumbnail(file, data) and display the image wherever you like. That is a deliberate trade-off: Dropzone does not dictate your markup, so you write the DOM code, but you also keep full control of it.

Uploads go over XHR, and the feature list names chunked uploads for large files plus support for Amazon S3 Multipart. The documentation also mentions browser image resizing, which resizes images before they reach your server. If you are uploading phone photos, that changes the payload size your endpoint sees, and it is one of the few places where the library makes a decision that your backend will notice.

Installing Dropzone and uploading your first file

The Quickstart installs from npm, or from pnpm with the equivalent command. Both are given verbatim in the README.

npm install dropzone
# or with pnpm:
pnpm add dropzone

Then construct an instance against an element. The README recommends the ES6 module form:

import { Dropzone } from "dropzone";
const dropzone = new Dropzone("div#myId", { url: "/file/post" });

If your build is CommonJS, the same page gives the require form. The only required option in either example is url, which is the endpoint the files are posted to. Until you point it at a real route, the drop target will accept files and the upload will fail.

If you are not using a package manager or a bundler, the README documents standalone files served from unpkg, with the stylesheet loaded separately and Dropzone available as a global variable:

<script src="https://unpkg.com/dropzone@6/dist/dropzone-min.js"></script>
<link rel="stylesheet" href="https://unpkg.com/dropzone@6/dist/dropzone.css" type="text/css" />

<div class="my-dropzone"></div>

<script>
  const dropzone = new Dropzone("div.my-dropzone", { url: "/file/post" });
</script>

For TypeScript, the README shows importing DropzoneOptions and typing the options object, then attaching a listener. It notes that listener arguments are inferred from the event name, which is the practical benefit: you get file typed correctly on "addedfile" without annotating it yourself. The README points to src/options.ts in the repository for the full set of available options, and to a separate repository of example implementations for different bundlers.

Where Dropzone 6 stops being the right tool

The clearest limitation is stated by the project itself: Dropzone 6 does not support Internet Explorer, and the README directs anyone who needs it to 5.9.3. That splits the user base. If your support matrix still includes IE, you are on a branch whose API differs from the one the current documentation describes, and the TypeScript types shipped with version 6 will not describe what you are running.

The second boundary is trust. Dropzone runs in the browser and posts to your url. Validation, size limits enforced server-side, authentication and virus scanning are not its job. Client-side checks can be edited by the user, so a maxFilesize-style option is a convenience, not a control.

Third, the README routes support away from the issue tracker. It asks that you use the discussions section or Stack Overflow with the dropzone.js tag, and says to open an issue only if you believe you found a bug. If your team's habit is to file issues for questions, expect to be redirected.

The repository is also a monorepo now. The library, the Docusaurus documentation and the SvelteKit website live in one workspace, and the root package.json requires Node >=20.19.0 and [email protected]. If you only consume the published package this does not affect you. If you plan to patch it and send changes back, the CONTRIBUTING.md file is flagged in the README as required reading before you start.

Dropzone compared with hand-rolled XHR upload code

The realistic alternative is not another library so much as writing the upload layer yourself: a hidden input, dragover and drop handlers, a FileReader or createObjectURL for previews, and an XMLHttpRequest with an upload.onprogress listener.

The difference in approach is where the state lives. Hand-rolled code puts the file list, the progress values and the DOM nodes under your control, which is an advantage when the upload UI is unusual. Dropzone instead owns a file object per upload and emits events around it, and you subscribe. That inversion is why the library is quick to adopt and occasionally awkward to bend: theming is possible because the default look is just the default theme and you can overwrite the default event listeners, but you are working through the event model rather than around it.

A second difference is the feature set that comes bundled. Chunked uploads, S3 multipart and browser-side image resizing are substantial pieces of code to reproduce. If you need any of those, the comparison shifts heavily toward using the library. If you need a single small file posted to one endpoint with no preview, hand-rolled XHR is a few dozen lines and one less dependency.

For React users specifically, the README does not document a React wrapper. The examples repository is linked for bundler setups, not framework bindings, so a React integration is something you build on top of the same constructor and event API.

Maintenance, releases and what the licence metadata says

The last push to the repository was on 2026-09-16, and the release list shows [email protected], 6.3.3 and 6.3.2 all dated 2026-09-16. The repository is not archived. Versioning runs through Changesets: the root package.json exposes changeset, changeset:version and changeset:publish scripts, and there is a .changeset directory at the top level. For consumers, that means releases are cut deliberately rather than on every commit.

The upgrade cost is mostly about the major version. Moving from Dropzone 5 to 6 breaks Internet Explorer support, and the README points to the CHANGELOG for everything that changed in 6.0.0. It also invalidates the DefinitelyTyped package: if @types/dropzone is in your dependency tree, the README says to remove it, because it stopped at 5.7.9 and describes the v5 API. Leaving it installed alongside version 6 gives you two conflicting descriptions of the same import.

On licensing, there is a discrepancy worth flagging. The README ends with an MIT License heading and links to the LICENSE file, and the monorepo package.json declares "license": "MIT". The repository metadata, however, reports the licence as NOASSERTION, meaning the platform could not classify it automatically. That is a metadata classification, not a statement that the terms are unclear, but if your process depends on automated licence detection, it is the thing to check before you ship. This is not legal advice; read the LICENSE file and decide with whoever handles that for you.

Editorial conclusion

Dropzone fits teams that need drag-and-drop uploads with previews and progress inside an existing page, and who can accept a client-side library that leaves validation to the server. It is the wrong choice if Internet Explorer support is still required, since Dropzone 6 does not support it and the README points to 5.9.3 instead, or if you want a component that owns the whole upload flow including storage. Before adopting it, verify the LICENSE file, because the repository metadata reports the licence as NOASSERTION while the README and package.json both say MIT.

Frequently asked questions

Official sources

1. enyo/dropzone on GitHub
2. Issues
3. Project website
4. README
5. Releases