Choosing a file upload library
Most comparison tables list features nobody's decision actually turns on. These are the questions that do — including the ones where this library is the wrong answer.
1. Who writes the server half?
The biggest hidden cost. A browser library that only sends requests leaves you to implement chunk storage, assembly, validation, resume state and cleanup — that is the part with the security bugs in it. Ask specifically: does it ship a server implementation, a reference implementation, or nothing but a wire format?
MultipleUpload is backend-agnostic and ships a reference Node middleware plus documented request formats for other stacks. If you want the server half maintained for you on .NET, that is what the sibling products exist for.
2. Bundle size and dependencies
Check the dependency tree, not just the minified size. A library with a dozen transitive dependencies is a dozen future security advisories and a dozen things that can break your build. Zero-dependency is worth real weight if you maintain the app for years.
And be honest about what you need: if you upload one avatar per user, a 40 KB uploader with resumable multi-cloud transports is not a better choice than fifteen lines around fetch().
3. Which transports do you actually need?
| If your files are… | You need |
|---|---|
| Small (< 10 MB), on good networks | A single POST. Anything more is overhead. |
| Large, or users on mobile | Chunking with per-chunk retry |
| Large and interrupted often | Resume across page reloads (persisted state, or tus) |
| Large and stored in cloud object storage | Direct-to-cloud, so bytes never touch your server |
| Coming from Drive/Dropbox/Box | Remote sources — and a server-side OAuth broker if you care about token safety |
4. Framework coupling
A library built around one framework's component model is pleasant until you migrate. A framework-agnostic core with thin adapters survives the next rewrite. If a library only exists as a React component and you are on Vue — or on server-rendered HTML — that is a decision about your next five years, not just this sprint.
5. Accessibility
Frequently discovered late, during a procurement review. Check it yourself in ten minutes: can you select files, start an upload, and cancel one using only the keyboard? Is upload progress announced to a screen reader, or does the page just silently change? Do icon-only buttons have accessible names? A drop zone with no keyboard path is not usable by everyone, and in many contexts that is a legal problem rather than a preference.
6. Maintenance and licensing
- When did it last ship? An upload library that has not changed in three years has not responded to three years of browser changes.
- How are security issues handled? Look for a changelog that names them plainly rather than burying them in "bug fixes".
- What happens if it is abandoned? With open source you can fork; with a commercial component you are buying support — make sure you know which you are relying on.
- Does the license fit? Per-developer, per-server and per-application terms differ a lot at renewal time.
7. Try it with your worst file
Evaluations use a 2 MB PDF on office wifi and prove nothing. Test the case that actually hurts: your largest realistic file, on a throttled connection, with the network dropped halfway. Then reload the page and see what happens. That five-minute test separates libraries far better than any feature matrix — including this one.