Stop importing uuid. crypto.randomUUID() has been native since 2021.
The uuid npm package is one of the most downloaded libraries in the JavaScript ecosystem. The vast majority of those installs exist for one thing: uuid/v4 , which generates a random unique identifier in the standard xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx format. The browser - and Node.js - have been doing this natively since 2021. No package needed. The native API const id = crypto.randomUUID(); // "110e8400-e29b-41d4-a716-446655440000" That's the entire API surface. One call, no constructor, no configuration. It returns a v4 UUID string - the same format every UUID library produces, the same format your database expects. crypto.randomUUID() lives on the Web Crypto API's crypto object, which is globally available in browsers, Node.js, Deno, Bun, and Cloudflare Workers. No import required. Why it's safe to trust The uuid/v4 package generates UUIDs using crypto.getRandomValues() internally - the same source crypto.randomUUID() uses. Both draw from the operating system's CSPRNG (cryptographically secure pseudorandom number generator). The native method adds nothing risky; it's the same primitive, one level closer to the metal. // What uuid/v4 does internally (simplified): function v4() { const bytes = crypto.getRandomValues(new Uint8Array(16)); // ... set version and variant bits, format as string return formatted; } // What crypto.randomUUID() does: const id = crypto.randomUUID(); // same operation, no library The security profile is identical. The library adds no cryptographic benefit over the native call. Where it works crypto.randomUUID() is available in any secure context - HTTPS pages, localhost , Service Workers, Web Workers, and Node.js 14.17+. // In a Service Worker self.addEventListener('fetch', event => { const requestId = crypto.randomUUID(); console.log([${requestId}] ${event.request.url}); }); // In a Web Worker // Inside worker.js: const taskId = crypto.randomUUID(); postMessage({ taskId, status: 'started' }); The "secure context" requirement is the only constraint. If your page is served over HTTPS (or you're on localhost ), crypto is available everywhere the JavaScript runtime runs in that page - main thread, workers, service worker included. Replacing the import A direct swap, wherever you currently use uuid : // Before import { v4 as uuidv4 } from 'uuid'; const id = uuidv4(); // After const id = crypto.randomUUID(); The output format is identical. Whether you're generating IDs in a React component, a route handler, a database model, or a logging utility - it's a one-line change per call site. Once every call is replaced, you can remove the dependency from package.json . The one case where you still need a library crypto.randomUUID() generates v4 UUIDs only - random, no namespace. If you need: - v5 UUIDs (namespace + name, SHA-1 hash based): still use uuid/v5 - v3 UUIDs (namespace + name, MD5 hash based): still use uuid/v3 - Parsing or inspecting UUID bytes, version bits, or variant: still use the library If you're generating a unique ID for a database row, a request trace ID, a session token, or a UI list item key - v4 is the right choice. That's exactly what crypto.randomUUID() gives you. Browser support crypto.randomUUID() is Baseline 2022: Chrome 92 (July 2021), Firefox 95 (November 2021), Safari 15.4 (March 2022), Node.js 14.17 (May 2021). It has been in every supported browser and server runtime for years. There's nothing to polyfill for any currently-maintained target. ๐ฎ Try it yourself โถ๏ธ Open the interactive playground โ Runs right in your browser - poke at it and watch the concept react live. ๐ง Test yourself Think it clicked? Take the 9-question quiz โ Instant feedback, a hint on every question, and an explanation for each answer - right or wrong. The takeaway Open your package.json . If uuid is listed and your codebase only uses v4 , remove it. Search for uuid/v4 , uuidv4() , or import { v4 } and replace each call with crypto.randomUUID() . You get the same string format, the same randomness quality, and zero added bundle weight. For v4 UUIDs - the most common case by a wide margin - the native method is strictly better than the library it replaces. Thanks for reading! Let's stay connected: - โญ GitHub - follow me and star the projects: github.com/parsajiravand - ๐ฌ Discord - join the frontend best-practices community: discord.gg/d9KRhuAwQ - ๐ธ Instagram - frontend best practices, daily: @bestpractice___ - ๐ผ LinkedIn - linkedin.com/in/parsa-jiravand - โ๏ธ Email (work & contract inquiries): bes*************@gmail.com Top comments (0)
Comments
No comments yet. Start the discussion.