UUID Generator v4 & v7

Random v4 or time-ordered v7, in bulk, in the format you need.

crypto.getRandomValues, never Math.random
Advertisement

First one, in detail

—
UUIDs 
Press Generate.
Java 

            

          

        


        

        

          Generated —
          Version —
          Size 0 B
          Ready
        

      


      

        

          

            
v4 or v7 — which one

            
Both are 128 bits and both are unique in practice. The
              difference only shows up once they are a database key.

            
    
              
  • v4 is 122 random bits. Every insert lands at a random point in the index, so a
                busy table keeps rewriting pages all over the B-tree and the working set stops fitting in memory.
                Perfect when the id must reveal nothing.
    • 
              
  • v7 puts 48 bits of Unix milliseconds first, so ids sort by creation time and
                inserts append instead of scattering. That is the whole reason it exists, and why it is the better
                default for a primary key.
    • 
              
  • The trade with v7 is that the row's creation time is readable from its id. If the
                id is a public token, that is a leak — use v4.
    • 
              
  • Java: UUID.randomUUID() is v4. There is no v7 in the JDK yet, so the
                snippet on the right builds one from the clock, a counter and SecureRandom. The
                counter is what keeps ids made in the same millisecond in order — without it, roughly half
                of a burst comes out shuffled and the append-only insert pattern is lost.
    • 
            

          

        

      


      

        

          
Frequently asked questions

          

            
Are these UUIDs generated on your server?

            
No. They are made in your browser by crypto.getRandomValues, the same
              cryptographic source a password manager uses, and nothing is sent anywhere. Closing the tab is enough to
              destroy them.

            
Can two UUIDs ever collide?

            
Not in practice. A v4 has 122 random bits, so you would need to generate about 2.7
              quintillion of them before a collision reached even a one-in-a-billion chance. The realistic risk is a
              weak random source, not the maths — which is why Math.random is never used here and
              why SecureRandom, not Random, belongs in the Java version.

            
Why does the Java v7 snippet keep a counter?

            
Because the timestamp only has millisecond resolution. Two ids stamped in the same
              millisecond would otherwise be ordered by their random tail, so a burst of inserts scatters across the
              index — the one thing v7 is chosen to avoid. The 12 bits after the version hold a counter that
              breaks those ties, as RFC 9562 suggests. It is also why the method is
              synchronized and the SecureRandom is a single shared instance.

            
Can I recover the creation time from a v7?

            
Yes, and so can anyone else who has the id. The first twelve hex characters are the Unix
              time in milliseconds, which this page decodes for you under the first result. That is useful in a
              database and a leak in a public token, so use v4 wherever the id is exposed.

            
Is a UUID the right primary key for my table?

            
It is when rows are created in more than one place, or when an id must not reveal how many
              rows you have. Store it as 16 bytes rather than a 36-character string, and prefer v7 so inserts append to
              the index instead of landing at random.

            
What is the difference between a UUID and a GUID?

            
Nothing, at this level. GUID is Microsoft's name for the same 128-bit value, which is why
              it usually appears in braces and sometimes in uppercase. Both formats are in the dropdown above.

          

        

      

      

      

        
More free tools