NiftyWebTools
Start free
Nifty Tools
Free uuid generator in your browser. v4 and v7, bulk up to 1000, hyphenated/braces/uppercase formats, RFC 4122 + RFC 9562. No upload, no signup.
Processing mode: Local Browser-local
Keep working
JWT Decoder — Free, In Your Browser
Use a free jwt decoder in your browser to read JWT header and payload. Base64URL decode, exp and iat highlighted, browser-local. No signature verification.
Base64 Encoder — Free, In Your Browser
Use a free base64 encoder in your browser. Encode text, files, and data URIs locally. UTF-8 safe, URL-safe output. No upload, no signup.
Base64 Decoder — Free, In Your Browser
Use a free base64 decoder in your browser. Decode Base64 to text or files, with URL-safe, padding repair, and data: URI support. No upload.
URL Decoder — Free, In Your Browser
Use a free url decoder in your browser. Decode percent-encoded URLs, query strings, and OAuth redirects locally. No upload, no signup.
JSON Formatter
Format, minify, and validate JSON in a clean browser-based workspace.
Case Converter — Free, In Your Browser
Case converter for upper, lower, title, sentence, camel, Pascal, snake, kebab, and constant case. Runs in your browser. No upload, no signup.
QR Code Generator
QR code generator for links, menus, posters, and labels — with custom colours, logo overlay, and ECC tuned automatically so the code still scans.
JSON Diff — Compare Two JSON Values, In Your Browser
Run a json diff in your browser. Compare two JSON values structurally and read the change list by path. Pure JSON.parse, JSON Pointer paths, no upload.
How to use it
Good for
People reach for a uuid generator when something downstream needs a unique identifier and the obvious sources — auto-increment integers, content hashes, timestamps, sequential numbers — would either fail outright or carry information you do not want them to carry. The classic shapes are an idempotency key for a payment API retry (Stripe's `Idempotency-Key` header expects a UUID-shaped string and uses it to deduplicate retries within 24 hours so a network blip never charges a card twice); a primary key for a distributed system where two regions can write at once and there is no single coordinator handing out integers (multi-region SaaS, offline-first mobile apps, event-sourced systems); a test fixture or seed-data ID that is realistic enough to flow through validation but cannot collide with anything in production (preventing the "delete from users where id = 1" mistake that erases a real account); an external-system foreign key (Salesforce External ID, GoHighLevel external_id, HubSpot custom-object IDs — the common upsert pattern in marketing-automation tooling); a session ID that is long enough that brute-forcing it is not a viable attack (where the entropy floor matters more than the format); or simply a cache-busting suffix on a build asset URL where collisions across deploys would silently serve stale files. Two formats matter today: v4 (RFC 4122, 2005) is 122 bits of cryptographic random plus six bits of version/variant tags — the right default when you do not need sortable IDs; v7 (RFC 9562, May 2024) prefixes the same kind of identifier with a 48-bit millisecond Unix timestamp so the IDs sort by creation time, which gives B-tree indexes much better locality and turns the database-primary-key story from "random scatter" into "append-mostly." Generating either browser-locally matters because the IDs you produce here will routinely land in production databases, payment-API headers, customer record IDs, and signed tokens — places where treating an ID as an entropy source means the source has to actually be entropy-bearing. The page calls `crypto.randomUUID()` for v4 (a single browser API call backed by a CSPRNG, no library import) and a hand-rolled `crypto.getRandomValues()` pipeline for v7 (no native v7 generator exists in any browser as of 2026-04-27 — the spec landed too recently). Both formats are output in the canonical 8-4-4-4-12 hex layout; the page can also strip hyphens, uppercase the output, or wrap each ID in `{...}` for codebases that adopted Microsoft's GUID convention.
Processing mode
Files are processed by your browser. They never reach our servers.
Questions
v4 (RFC 4122, 2005) is 122 bits of random plus six bits of version and variant tags — pure scatter, no information about creation time. v7 (RFC 9562, May 2024) reuses the same 128-bit envelope but replaces the first 48 bits with a millisecond Unix timestamp, leaving 74 random bits after version and variant. The practical difference is index locality: v4 IDs land randomly across a database B-tree, which means inserts touch random pages and the cache-hit ratio collapses on hot tables; v7 IDs land in mostly-append order, which keeps the working set small and write throughput high. Pick v7 for database primary keys, event-sourced log IDs, and anything that benefits from being roughly sortable. Pick v4 for idempotency keys, session IDs, password-reset tokens, and anywhere the timestamp would leak information you do not want exposed (see the v7-leakage FAQ).
Yes. The Web Crypto spec requires the UA to source the bits from a CSPRNG — the same entropy source as `crypto.getRandomValues()` and the same source TLS, password hashing, and signed-cookie generation use in the browser. The spec also requires the version-and-variant bits to land in the right positions, which means an output passes RFC 4122 validation by construction. The implementation lives in the browser engine (V8, JavaScriptCore, SpiderMonkey), not in user code, so a downstream library cannot accidentally weaken it. v7 uses the same `crypto.getRandomValues()` source for the random bits — no degradation. Note that "cryptographically secure random" is a different property from "globally unique" — collisions are statistically negligible (the v4 collision probability across 1 billion IDs is roughly 1 in 4 × 10¹⁰), but the cryptographic guarantee is about unguessability, not uniqueness.
For v4, no — the 122 random bits are independent of any clock, and the collision probability across two billion UUIDs is approximately 4 × 10⁻¹⁰. For v7, also no, but with a wrinkle around ordering: RFC 9562 §6.2 *allows* implementations to reuse the 12-bit `rand_a` field as a monotonic counter so that same-millisecond IDs from one generator sort lexically, but it does not require it — random `rand_a` and `rand_b` are conformant, and the spec lists counter-monotonicity alongside several other "optional" methods for additional ordering. This page takes the random path: the 74 random bits after the timestamp are drawn from `crypto.getRandomValues()` per ID, so multiple v7 IDs generated in the same millisecond in a bulk run will share the timestamp prefix but will *not* be lexically ordered relative to each other. If your downstream system depends on strict lexical order within a millisecond — most do not, because the millisecond resolution is already finer than the consumer's wall-clock — generate one ID per call and rely on the Date.now() tick advancing between calls, or use a server-side library that implements the §6.2 counter pattern. Across two different generators (two browsers, two servers, two regions) within the same millisecond, the 74 random bits give a collision probability of roughly 5 × 10⁻¹² per same-millisecond pair — also negligible.
Yes — the first 48 bits of a v7 UUID are the literal `Date.now()` millisecond value, which means anyone who sees the ID can recover the creation time to the millisecond. That is not a flaw, it is the entire point of the format. It matters when the timestamp itself is sensitive: a session ID that reveals when the user logged in, a password-reset token that reveals when the request was made, an idempotency key that reveals when the charge was attempted — those use cases want v4, not v7. Customer record IDs, transaction IDs, audit-log IDs, and database primary keys generally do not have this problem because the creation time is already recorded in a separate `created_at` column, so the ID exposing it adds no new information. The conservative rule is: if the value is going in a column called something like `id` and there is a separate `created_at` next to it, v7 is fine; if the value is going in an HTTP header or a URL fragment that an external party will see, v4 is the safer default.
Postgres has a native `uuid` type that accepts the canonical hyphenated form (`xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx`) directly — copy-paste from this page works. MySQL has no native UUID type but accepts `CHAR(36)` for the hyphenated form or `BINARY(16)` for the packed form (the page outputs the hyphenated form; MySQL clients and ORMs typically pack to binary on insert). MongoDB stores UUIDs as `BinData` subtype 4; the official drivers parse the canonical hyphenated string into the binary form on insert. Stripe accepts UUID-style or high-entropy random strings in the `Idempotency-Key` header (the contract is "high-entropy" rather than UUID-only, but a hyphenated UUID from this page satisfies it directly). The "no hyphens" output format is for systems that store UUIDs as 32-character hex (some older MySQL apps and most HTTP-header-as-string contexts); the "uppercase" and `{braces}` formats are for codebases that inherited the Microsoft GUID convention (most C# / .NET / SQL Server work).
No. A thousand `crypto.randomUUID()` calls complete in well under 5 ms on every device the page has been tested on (a 2018 mid-range Android phone is the slowest of the test set), and the resulting text is roughly 37 KB — small enough that rendering it into the output textarea is also imperceptible. The 1000-ID cap is a guard against accidental paste-of-a-very-large-number rather than a performance limit; if you genuinely need more, run the page twice. The cap applies to a single Generate click, not to total session output — clearing and regenerating ten times will produce 10,000 unique IDs with no degradation.
v1 (timestamp + node) historically embedded the generator's MAC address in the node field, which leaked hardware identity; modern v1 implementations randomise the node field, but at that point you have most of v7's properties without v7's better random/timestamp split — the JavaScript ecosystem has converged on v7 as the modern timestamp-ordered choice. v3 (MD5-namespace) and v5 (SHA-1-namespace) are deterministic IDs derived from a namespace UUID plus a name string — useful when the same input must always map to the same UUID (deduplicating an API response into stable IDs, for example), but they require user input that the page would have to accept and validate, and the use case is niche enough that a dedicated tool is the right shape for it. v6 (RFC 9562 v6) is a re-ordering of v1's bits to be sortable; v7 is the recommended replacement and the spec marks v7 as the preferred new-design choice. v8 is intentionally application-defined and has no canonical generation algorithm. The page covers the two formats the vast majority of real workflows need and does not pretend to cover the long tail.
No. `crypto.randomUUID()` and `crypto.getRandomValues()` are native browser APIs that run inside this tab and source their entropy from the operating system's random pool — the same pool TLS handshakes, password hashing, and cookie signing use. The generated IDs, the output textarea, and any download all stay on your device. There is no signup, no watermark, no analytics on the IDs themselves. Safe for IDs that will land in production databases, payment-API idempotency headers, signed tokens, and external-system foreign keys.
The basic workflow is designed to stay free. Paid upgrades later will focus on bigger limits, batch work, OCR, saved presets, and ad-free use.