UUID 批量生成
批量生成 UUID v1、v3、v4、v5、v6、v7、v8,可输出标准、大写、无横线、花括号、URN、TXT、JSON。
AK
appkiro.com1 - 1000
Generated
0
UUIDs
Valid
0
0%
Invalid
0
0%
Unique
0
0%
UUID Generator produces unique 128-bit identifiers in the canonical 8-4-4-4-12 hex layout, with full support for every version defined in RFC 4122 and RFC 9562. Pick a version from the dropdown, choose how many values to mint, and the table on the right fills with results that you can copy, download as TXT or JSON, or feed into the built-in preview panel for byte-level inspection.
Engineers reach for a generator like this when seeding a fresh database, scaffolding fixtures for a test suite, populating environment variables, or creating sample identifiers for documentation and screenshots. Because everything runs in the browser and uses the operating system's cryptographic random source, the values are safe to drop straight into production code.
v4 is the most-used default for random keys. v7 is the modern pick when records need to sort by creation time. v1 and v6 carry timestamps and a node field. v3 and v5 are name-based hashes; v8 leaves layout to the application.
Standard lowercase fits most APIs. Uppercase matches the GUID style used by some Windows tooling. Hyphenless is convenient for URL paths. Braces match Microsoft COM style. URN follows the IETF identifier scheme.
The quantity field accepts up to 1000 values per batch. The Download (JSON) button produces a structured file with index, canonical form, version, variant, and timestamp where applicable.
Generation runs entirely on your device. Nothing is uploaded, logged, or remembered after the tab closes. The Auto copy option places the latest batch on the clipboard if you prefer to skip the table click.
For new application tables, prefer v7 — the leading bytes are time-ordered, so inserts cluster at the index tail and B-tree fragmentation stays low. For identifiers that should leak no metadata, v4 is the right call. v1 is still common in legacy systems, but the embedded MAC address and microsecond-resolution timestamp can be more information than is desired in modern services.
Use v4 when ordering does not matter and you want random keys with no embedded metadata. Use v7 when records will be inserted into a database index or stored in a log, because the leading bytes are time-ordered and writes cluster naturally at the tail of the index.
Yes. The page calls the browser's crypto.getRandomValues and crypto.randomUUID interfaces, which are backed by the operating system's secure random source. The randomness available here is the same that browsers use for session tokens and TLS keys.
Both encode a 60-bit timestamp counted in 100-nanosecond intervals since 1582. v1 stores the bytes in a layout that does not sort lexicographically. v6 rearranges the same bytes so that text-sorted UUIDs are also chronologically ordered, which makes v6 friendlier for database indexes.
v7 puts a 48-bit Unix-millisecond timestamp in the leading bytes. Sequential generations land near each other in the B-tree index, which keeps inserts in a hot page rather than scattering writes across the table.
No. Generation, formatting, statistics, and downloads all run in the browser. Closing the tab is enough to discard the values.
Yes. The quantity field accepts any value between 1 and 1000. Larger batches stream into the table and are downloadable as TXT or JSON.
Standard is canonical lowercase. Uppercase converts to all caps. Hyphenless drops the dashes (32 hex characters). Braces wrap the value in {}. URN prefixes urn:uuid: for IETF-style identifiers.