The Dropbox JavaScript SDK is one package with four builds

A generated API surface

The API reference section lists four entry points and the first of them is the important one. The Dropbox class provides the API routes for files, sharing, users, teams and other namespaces. The DropboxAuth class handles OAuth URLs, PKCE, access tokens and token refresh. The DropboxResponseError class carries the errors returned by API requests. And the Global API is the generated methods and route type definitions, which is where the shape of the SDK comes from. The repository has a generator/ directory, so the route methods are produced from a description of the API rather than written by hand, and the complete generated API reference is published on GitHub Pages. The practical consequence for a user is that the method names and argument types follow the API's own naming rather than a hand-designed surface, which is exactly what you want when a route changes upstream.

What the runtime has to provide

The runtime support section is short and specific. The SDK supports Node.js 22 and newer, modern web browsers, and Web Workers, and continuous integration currently tests Node.js 22 and 24. On Node the SDK uses the built-in fetch implementation, so there is no fetch polyfill to install there. Browser and Worker environments must provide Promise, fetch and TextEncoder, and PKCE authentication also requires the Web Crypto API, with the instruction to add polyfills when targeting older environments that do not provide the required APIs. The TextEncoder requirement is a good example of a modern assumption that bites in an old browser or in a server side rendering path, and the Web Crypto requirement is a stricter one, since it is not polyfillable in a straightforward way in every environment. Node 22 as the floor is a change of generation for a package that has been around long enough to have supported older runtimes.

One package, four distributions

Installation is a single npm command:

npm install dropbox

and the published packages already contain CommonJS, ES module, browser and TypeScript builds, so applications do not need to build the SDK from source. The package file shows where each build lives, with main pointing at cjs/index.js, module and jsnext:main at es/index.js, browser at dist/Dropbox-sdk.min.js and types at types/index. The build scripts explain how they are produced, with Babel compiling src and lib into the ES and CommonJS trees, and Rollup building the UMD bundles for the browser in both normal and minified forms. The Node usage is the require form with a client constructed from an access token:

const { Dropbox } = require('dropbox');

const dbx = new Dropbox({
  accessToken: process.env.DROPBOX_ACCESS_TOKEN,
});

dbx.filesListFolder({ path: '' })
  .then(({ result }) => console.log(result.entries))
  .catch(console.error);

A bundler based browser application uses the ES module build instead, with an import statement and the same constructor, and the Webpack, Rollup and Vite tools are named explicitly as the ones that can use it.

The CDN path, and the advice to pin a version

Loading the SDK from a CDN exposes it through a global Dropbox object, and the example pins an exact version:

<script src="https://cdn.jsdelivr.net/npm/[email protected]/dist/Dropbox-sdk.min.js"></script>
<script>
  const dbx = new Dropbox.Dropbox({ accessToken: 'YOUR_ACCESS_TOKEN' });
</script>

The documentation is explicit about why the version is pinned, so that a future breaking release cannot change your application unexpectedly, and for debugging there is an unminified bundle at the same path without the min suffix. The same browser bundle can be loaded in a Web Worker with importScripts, and the worker gets the same global object. One line in that section is worth repeating to yourself before you ship, which is the instruction not to hard-code production access tokens in public source code, since a token in a bundled script is a token in the repository.

PKCE is the browser rule, not an option

The authentication section is the one to read carefully, and it is short. Client side applications cannot keep an app secret confidential, so never embed a Dropbox app secret in browser or Worker code, and the instruction is to use the OAuth authorization-code flow with PKCE and your app key instead, with links to a browser PKCE example and the OAuth guide. PKCE requires a secure context and the Web Crypto API, which is a deployment constraint rather than a code one, since a page served over plain HTTP will not work. Server applications can keep an app secret confidential and may use the regular authorization-code flow, so the two deployment models use different flows, and the SDK supports both through the DropboxAuth class. The examples directory makes the same split visible, with a simple auth example, a node backend doing a multi-step flow for short lived tokens, a PKCE backend, and a PKCE browser example.

File transfer helpers for the big files

For Node applications that need resumable local downloads or retrying uploads, the SDK exports file transfer helpers alongside the generated API methods. The names cover the range of strategies, with downloadFile, fileUpload, bytesUpload, readerUpload and sizedReaderUpload, plus a DropboxFileUploader class. The usage shows the shape:

const {
  Dropbox,
  DropboxFileUploader,
  bytesUpload,
  downloadFile,
  fileUpload,
  readerUpload,
  sizedReaderUpload,
} = require('dropbox');

const dbx = new Dropbox({ accessToken: process.env.DROPBOX_ACCESS_TOKEN });

await downloadFile(dbx, '/large-file.bin', './large-file.bin', {
  parallelDownloads: 4,
  progress: ({ bytesWritten, totalBytes }) => {
    console.log(`${bytesWritten}/${totalBytes}`);
  },
});

The parallelDownloads option and the progress callback are the two details that make it usable in an application with a progress UI. The examples directory has the matching material, with a backend download example showing resumable downloads to local storage, a download example for a shared file, an upload example, and team examples for listing team devices and acting as a user, most of them in both JavaScript and TypeScript.

The repository around the package

The tree is a mature npm package layout with a generator in it. There is src/ for the hand written source, lib/ for the generated or prebuilt library code, generator/ for the code that produces the route methods, types/ for the TypeScript declarations, index.js as the package entry, and test/ with unit, integration, build and type tests. The tooling is Babel for the module builds, Rollup for the browser bundles, ESLint for linting, nyc for coverage, jsdoc for documentation generation with a .jsdoc.json, and mocha for the tests, with a separate tsc build over the type tests. The build pipeline itself is one script that chains the four builds:

        "build": "npm run build:es && npm run build:cjs && npm run build:umd && npm run build:umd:min",

There is an UPGRADING.md for the breakages, a CODE_OF_CONDUCT.md, a codecov.yml, a rollup.config.js and a .babelrc. The version in the package file is 10.57.0 while the published releases listed for the project are v10.47.0 from 2026-09-23, v10.38.0 from 2026-07-23 and v10.37.0 from 2026-07-17, so the package version runs ahead of the tags, and the last push was on 2026-10-20. The licence is MIT and the homepage points at the Dropbox developer site.

Editorial conclusion

The SDK fits a JavaScript or TypeScript application that talks to Dropbox from Node, from a bundler or from a browser, and the four published builds mean you do not build the SDK yourself. It does not fit a browser application that wants to keep a client secret, because the documentation is explicit that a client side application cannot keep an app secret confidential and that PKCE is the answer, and it does not fit a project on an old runtime, since Node 22 and newer is the floor and older environments need polyfills. Before you adopt it, decide where the code runs and pick the matching build, read the browser PKCE example if the code is client side, and check the version you pin, because the package file reads 10.57.0 while the listed releases include v10.47.0.

Frequently asked questions

Official sources

1. dropbox/dropbox-sdk-js on GitHub
2. License: MIT
3. Project website
4. README
5. Releases