UUID v1 Generator
Timestamp + node based UUIDs, generated locally
Every UUID is generated and decoded in your browser using Web Crypto. Nothing is ever uploaded or stored on a server.
Version 1 is the original UUID from the 1990s DCE spec: a 60-bit timestamp accurate to 100 nanoseconds, a random clock sequence, and a "node" field that was originally meant to be your network card's MAC address. Browsers can't read your MAC address, and this tool wouldn't send it anywhere if it could, so the node here is a random value with the bit that marks it as "not a real hardware address" set, exactly as RFC 4122 allows.
What's inside a v1 UUID
Three pieces make up the identifying part of a v1 UUID: a 60-bit timestamp measured in 100-nanosecond intervals since October 15th, 1582 (the date the Gregorian calendar was adopted, chosen by the original spec authors as a fixed reference point), a clock sequence to avoid collisions if the clock ever moves backward, and a 48-bit node value. Paste any v1 UUID into the inspector and it decodes that timestamp back into a real date for you.
tttttttt-tttt-1ttt-cccc-nnnnnnnnnnnn └── timestamp ──┘ └clk┘ └── node ──┘
Why the "node" here isn't your MAC address
The original spec really did use the machine's MAC address, on the assumption that no two devices would share one, which made the whole UUID unique by construction. That turned out to be a real privacy leak: it meant a UUID could be traced back to the exact machine that generated it. RFC 4122 §4.5 provides the fix: when a real hardware address isn't available, or you'd rather not use it, generate 48 random bits instead and set the low bit of the first byte, the "multicast" bit, to 1. A real MAC address is never supposed to have that bit set on a real network card, so it's a clean signal that the node is synthetic. That's what this tool does; it never touches, and couldn't touch, any hardware identifier on your device.
When v1 still makes sense
You'll mostly run into v1 today for compatibility, some older databases, protocols, and libraries default to it. If you're integrating with a system that specifically expects v1, this generates a spec-correct one. For anything new, v4 or v7 are almost always the better call: v4 if you want maximum unpredictability, v7 if you want the sortability without the legacy baggage of v1's node and clock-sequence fields.