ID Toolkit
All processing happens in your browser. No data is sent to any server.
About this tool
Choosing an ID format
The right ID format depends on your system's requirements for sortability, size, compatibility, and metadata encoding. UUID v4 offers maximum compatibility because virtually every language, database, and framework has built-in UUID support, but its random nature causes B-tree index fragmentation in databases. UUID v7 solves this by placing a millisecond Unix timestamp in the most significant bits, giving you chronological sort order while retaining the standard UUID format and broad ecosystem support. Choose UUID v7 for new projects that need sortable IDs without abandoning the UUID standard. ULID provides the same 128-bit capacity and millisecond timestamp as UUID v7 but uses a compact 26-character Crockford Base32 encoding with no hyphens, making it ideal when you need URL-safe, human-readable identifiers. Snowflake IDs are 64-bit integers that embed a millisecond timestamp, worker ID, and datacenter ID, making them the best choice for distributed systems with worker-level sharding where a compact numeric ID is required. KSUID uses a second-precision timestamp with a 128-bit random payload in a 27-character Base62 string, offering time-sortable identifiers with extremely low collision probability when millisecond precision is not needed.
Extracting timestamps from IDs
Several popular ID formats embed creation timestamps directly in their binary structure, allowing you to determine when a record was created without querying a separate created_at column or metadata store. UUID v1 and v6 encode a 60-bit Gregorian timestamp with 100-nanosecond precision. UUID v7 stores a 48-bit Unix millisecond timestamp in the first 48 bits. ULID encodes the same 48-bit millisecond timestamp in its first 10 Crockford Base32 characters. Snowflake IDs embed a 41-bit millisecond timestamp relative to a platform-specific epoch such as Twitter's (2010-11-04) or Discord's (2015-01-01). KSUID stores a 32-bit second-precision timestamp offset from May 13, 2014. This tool automatically detects the ID format, extracts the embedded timestamp, and displays it in both UTC and your local timezone. Common use cases include determining record creation times during database forensics, debugging event ordering in distributed systems, and verifying that ID generation is producing monotonically increasing values. Use the JWT Debugger to decode another common token format that embeds timestamps and structured claims.
Frequently Asked Questions
What is a UUID and what versions exist?
UUID (Universally Unique Identifier) is a 128-bit identifier standardised in RFC 9562 (formerly RFC 4122), represented as 32 hexadecimal digits separated by hyphens in the 8-4-4-4-12 format. There are seven defined versions. Version 1 encodes a 60-bit Gregorian timestamp and the node MAC address, providing chronological ordering but leaking hardware identity. Version 3 and version 5 are name-based, generating deterministic IDs by hashing a namespace and name with MD5 or SHA-1 respectively. Version 4 is entirely random, using 122 bits of cryptographic randomness, making it the most widely adopted version for general-purpose unique identifiers. Version 6 is a reordered variant of v1 that places the timestamp bits in most-significant-bit order for better database index locality. Version 7, introduced in RFC 9562, combines a 48-bit Unix millisecond timestamp with 74 bits of randomness, offering both chronological sortability and strong uniqueness without exposing hardware information. Version 7 is the recommended choice for new applications that need time-ordered identifiers.
What is a ULID?
ULID (Universally Unique Lexicographically Sortable Identifier) is a 128-bit identifier designed as a sortable alternative to UUID v4. It is encoded as 26 characters using Crockford Base32, which excludes ambiguous characters like I, L, O, and U to improve readability and reduce transcription errors. The first 10 characters encode a 48-bit Unix millisecond timestamp, providing chronological sort order when IDs are compared as strings. The remaining 16 characters encode 80 bits of cryptographically secure randomness, ensuring uniqueness even when multiple IDs are generated within the same millisecond. Unlike UUID, ULID has no hyphens and uses a compact encoding that fits in fewer characters while carrying the same 128 bits of information. ULIDs are monotonically sortable, meaning database indexes built on ULID primary keys avoid the random insertion patterns that degrade B-tree performance with UUID v4. The format is particularly popular in event sourcing systems, distributed logs, and any context where lexicographic ordering by creation time is valuable without requiring a centralized sequence generator.
What is a Snowflake ID?
Snowflake is a 64-bit distributed ID format originally created by Twitter to generate unique IDs across thousands of servers without coordination. The format divides the 64-bit integer into four segments: 1 unused sign bit, 41 bits for a millisecond timestamp relative to a custom epoch, 5 bits for a datacenter identifier, 5 bits for a worker (machine) identifier within that datacenter, and 12 bits for a per-worker sequence number. This structure allows each worker to generate up to 4096 unique IDs per millisecond independently. The 41-bit timestamp provides approximately 69 years of range from the chosen epoch. Discord, Instagram, and many other platforms use the Snowflake concept with their own epoch values and different bit allocations for the machine and sequence segments. Because Snowflake IDs are standard 64-bit integers, they are compact, fit in a single database column, and can be sorted chronologically by numeric value. This tool auto-detects common Snowflake epochs and lets you specify a custom epoch for proprietary implementations.
What is a KSUID?
KSUID (K-Sortable Unique IDentifier) is a 160-bit identifier designed by Segment for use in distributed systems that require time-ordered unique keys. It is encoded as a 27-character Base62 string, making it URL-safe and compact. The structure consists of a 32-bit unsigned integer representing seconds since the KSUID epoch of May 13, 2014 (chosen to maximise the usable timestamp range), followed by a 128-bit cryptographically random payload. The second-precision timestamp means KSUIDs generated within the same second share the same time prefix but remain unique due to the large random component. Unlike ULIDs which use millisecond precision, KSUIDs trade timestamp granularity for a larger random payload, reducing the probability of collision in high-throughput scenarios. KSUIDs sort lexicographically by creation time because Base62 encoding preserves the numeric ordering of the underlying bytes. They are widely used as database primary keys, distributed trace IDs, and event identifiers in systems where chronological ordering simplifies debugging and data retrieval without requiring database-generated sequences.