ng2-file-upload: Angular File Selection, Drop Zones, and XHR Uploads
Easy to use Angular components for files upload
At a glance
- What is it?
- ng2-file-upload gives Angular applications file selection, drag-and-drop, queue controls, filtering, progress events, and XHR uploads through FileUploader. Its main constraint is strict coupling between the uploader version and the Angular major version.
- Who is it for?
- Adopt ng2-file-upload when an Angular application needs its established FileUploader queue and XHR behavior, especially with manual upload, filtering, or service-owned uploads. Do not choose it merely because its name sounds current: verify the published package version against your Angular major, confirm that credentialed cross-origin uploads match the server policy, and decide who owns change detection before integrating queue state into the interface.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 16 days ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on October 22, 2026, and from our analysis. They are not legal advice.
Editorial analysis
Where ng2-file-upload fits in an Angular application
ng2-file-upload addresses the browser-side part of an HTTP file upload workflow in Angular. It is for applications that need a file input, a drop area, an upload queue, validation options, progress reporting, and request construction without writing those mechanics directly for each screen. The repository describes it as a set of Angular directives for uploading files, and its primary language is TypeScript.
The library exposes two interaction directives. `ng2FileSelect` connects an HTML file input to a `FileUploader`, while `ng2FileDrop` connects a drag-and-drop area to the same kind of uploader. The `FileUploader` class holds queued items, applies filters, and sends uploads through XHR callbacks. This separates the selection surface from the request machinery, so a form can offer both a conventional file picker and a drop target without implementing both separately.
It is intended for Angular developers who need multipart or direct-body uploads rather than a complete storage service. The library does not document server persistence, object storage administration, malware scanning, or business-level attachment processing. The configured URL must point to an upload route that the application operator already controls or trusts. It is therefore the wrong tool when the requirement is a hosted upload platform with its own dashboard, retention policy, and storage lifecycle.
How ng2-file-select, ng2-file-drop, and FileUploader connect
The data flow begins when a user selects or drops files. The relevant directive passes those browser `File` objects to its associated `FileUploader`, and the uploader adds them to its queue. The README states that queue additions run through the uploader filters. Selection and drop do not necessarily start network requests because `autoUpload` defaults to `false`. In that default mode, application code can call `uploader.uploadAll()` after the user confirms the queue.
`onFileSelected` exposes the selected `FileList` as `$event`, and `onFileDrop` exposes the dropped `FileList` after addition to the queue. The documentation suggests `Array.from($event)` when an array is needed. For `ng2FileDrop`, `fileOver` reports `true` while files are dragged over the area and `false` after they leave or are dropped. These events support interface state such as a visual hover indicator.
The uploader can construct multipart requests by default. Configuration controls the request method, headers, authentication header name and value, multipart field alias, extra form fields, and whether additional fields appear before files. It also supports `disableMultipart`, which sends the file itself as the request body. The documentation cites APIs such as Amazon S3 as a possible use for that mode. An asynchronous `formatDataFunction` can transform the body when `disableMultipart` is enabled.
File and request options share one queue model. `maxFileSize`, `allowedMimeType`, and `allowEmptyMimeType` constrain incoming files. Authentication and additional form fields apply to requests. This makes the class convenient for common Angular forms, but it also means request policy and user selection are configured through the same abstraction. Applications with highly specialized signing or transport requirements may need another layer.
Installing ng2-file-upload and importing Angular directives
The README identifies npm as the recommended installation route. This installs the published package into the Angular application being built, not the private `ng2-file-upload-demo` package named by the repository root `package.json`.
npm i ng2-file-uploadAfter installation, a standalone component imports `FileSelectDirective`, `FileDropDirective`, and `FileUploader`. An `NgModule` can instead import `FileUploadModule`. The compatibility table is the first constraint to check: it associates Angular 22.x with ng2-file-upload 11.x, Angular 21.x with 10.x, Angular 20.x with 9.x, and earlier Angular majors with their corresponding library lines. The release list includes v12.0.0 dated 2026-10-07, while the README table shown here maps Angular 22.x to 11.x. That discrepancy should be resolved against the package documentation for the version being installed rather than inferred.
The repository is not archived, and its last push was on 2026-10-07. Recent releases include v12.0.0 on 2026-10-07, v11.0.0 on 2026-10-01, and v10.0.0 on 2026-03-05. This shows recent release activity, but it does not remove the need to inspect migration notes for an Angular upgrade.
Building a first queued upload component
The following example is the README's standalone component pattern. It creates a `FileUploader` pointed at `/api/upload`, binds both selection and drop directives to it, and uploads every queued item when the button is clicked. Because `autoUpload` defaults to `false`, adding a file does not by itself trigger this request.
import { Component } from '@angular/core';
import { FileDropDirective, FileSelectDirective, FileUploader } from 'ng2-file-upload';
@Component({
selector: 'app-upload',
imports: [ FileSelectDirective, FileDropDirective ],
template: `
<div ng2FileDrop [uploader]="uploader" (fileOver)="over = $event">Drop files here</div>
<input type="file" ng2FileSelect [uploader]="uploader" multiple />
<button (click)="uploader.uploadAll()">Upload all</button>
`
})
export class UploadComponent {
uploader = new FileUploader({ url: '/api/upload' });
over = false;
}The drop zone changes `over` when the drag state changes, although the shown template does not use that flag to alter styling. The input's `multiple` attribute lets the browser select more than one file. Both routes add files to the same uploader. A component still needs to render queue entries, progress, success, errors, and cancellation if those states matter to its users.
For an `NgModule` application, the documented alternative is:
import { FileUploadModule } from 'ng2-file-upload';
@NgModule({ imports: [ FileUploadModule ] })The route behind `/api/upload` is application-specific. The README does not provide a server implementation, so a successful upload cannot be inferred from the Angular code alone.
Zoneless Angular requires explicit rendering updates
A notable limitation appears in applications using zone-less change detection, which the README calls the default for new Angular applications. `FileUploader` updates items and progress from XHR callbacks, but those callbacks do not automatically cause a zone-less application to re-render. Displaying stale queue state is therefore plausible if the application assumes Angular will react to every XHR update.
The documented correction is to enable `provideZoneChangeDetection()` among the application providers. An application that does not add zone-based detection can instead call `ChangeDetectorRef.markForCheck()` from every callback whose state it displays. Relevant callbacks include `onBeforeUploadItem`, `onProgressItem`, `onSuccessItem`, `onErrorItem`, `onCancelItem`, and `onCompleteItem`. Application-triggered operations such as `item.remove()` also require an update when their visible result depends on change detection. Signals are listed as another way to update displayed state.
This requirement affects more than the final success message. A progress bar can remain at its previous value, and a completed item can remain visible. Integrators need an ownership decision for every displayed transition. The README does not provide a complete zone-less component example, so simply copying the basic template does not settle this concern.
Uploader ownership also affects route navigation. The documentation recommends creating the uploader in a service when uploads should continue while users move between routes. A component-owned instance is simpler for an isolated screen, but the documented service boundary is the relevant choice for long-running work.
Credentialed uploads and filter edge cases
Requests are sent with `withCredentials` enabled. For a cross-origin server, the README requires the response to name the exact allowed origin in `Access-Control-Allow-Origin` and include `Access-Control-Allow-Credentials: true`. An endpoint that only allows ordinary cross-origin use may therefore require adjustment before the upload works. The project does not ship that server policy in the client library.
Applications that do not need credentials can set `item.withCredentials = false` in `onAfterAddingFile`. That setting is per upload item according to the documented location, and it changes the credential behavior of the request. Authentication headers are separately configurable through `authToken` and `authTokenHeader`, whose default header name is `Authorization`.
MIME filtering has another browser-specific edge. Browsers can report an empty MIME type when the operating system does not recognize an extension, with the README mentioning `.7z`, `.mkv`, and some older Office files as examples. `allowEmptyMimeType` defaults to `true`, so untyped files pass `allowedMimeType`. Setting it to `false` rejects anything outside the listed MIME types. To permit certain untyped extensions while still applying `allowedMimeType`, the README recommends retaining `true` and adding a filter that checks the extension.
This filtering is client-side intake policy. The README does not claim that it replaces server-side file validation, so acceptance by the Angular queue should not be treated as proof that an upload endpoint accepted the file.
Choosing between this library and a lower-level Angular upload path
ng2-file-upload is a practical alternative to building queue management, filtering, multipart assembly, progress tracking, and XHR callbacks directly in an Angular component. Its advantage is the shared `FileUploader` model behind both a file input and a drop zone, plus configurable headers, additional fields, direct-body uploads, and removal behavior.
A lower-level approach is a better fit when preprocessing must happen before queue admission. The README explicitly says the directives add files as soon as they are selected or dropped. To resize images first, the application must handle the input's `change` event or implement its own drop zone, then call `uploader.addToQueue(files)` with the processed results. Even after interception, `FileUploader` remains the upload and queue mechanism, so this is an alternative interaction path rather than a different transport library.
For services requiring custom request signing or transport behavior beyond the documented XHR options, an application may need to separate file preparation from its chosen HTTP client. The practical decision should therefore be based on the required preprocessing stage, queue model, version mapping, and server credential policy rather than feature-count comparisons.
Editorial conclusion
Adopt ng2-file-upload when an Angular application needs its established FileUploader queue and XHR behavior, especially with manual upload, filtering, or service-owned uploads. Do not choose it merely because its name sounds current: verify the published package version against your Angular major, confirm that credentialed cross-origin uploads match the server policy, and decide who owns change detection before integrating queue state into the interface.
Frequently asked questions
Which ng2-file-upload version supports my Angular version?
The README maps Angular 22.x to 11.x, 21.x to 10.x, and 20.x to 9.x. It also lists earlier mappings, but the displayed table and the v12.0.0 release entry do not form a complete version pairing for v12, so that discrepancy should be checked before installation.
Does selecting or dropping a file upload it immediately in ng2-file-upload?
Not by default. The directives add files to the uploader queue, while `autoUpload` defaults to `false`; the basic example calls `uploader.uploadAll()` from a button.
How can I keep ng2-file-upload uploads running across Angular routes?
The README recommends creating the `FileUploader` in a service instead of a component so its lifetime is not tied to route component teardown.
Why might ng2-file-upload progress not update in a zoneless Angular application?
The README states that XHR callbacks do not automatically trigger re-rendering without zone.js. It recommends `provideZoneChangeDetection()`, or explicit `ChangeDetectorRef.markForCheck()` or signal updates for every displayed callback state.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/valor-software-ng2-file-upload)