If you’ve ever poked around a database or looked at an API response and seen something like 550e8400-e29b-41d4-a716-446655440000 sitting where you expected a normal ID — yeah, that’s a UUID. I remember staring at one for a solid minute thinking whoever set up this database made some very questionable choices. Why not just use 1, 2, 3?
Took me a while to get it. Now I use them in almost every project and I’d feel weird going back to auto-increment IDs for most things.
My actual problem that UUIDs solved
I was building this app where the user fills out a form, and the moment they hit submit, the frontend needs to immediately show the new item in a list with a clickable link. Standard stuff. But the link needs an ID, and the ID comes from the database, and the database hasn’t saved it yet because the API call is still in progress.
So what do you do? You show a loading spinner, wait for the server to respond with the new ID, then update the list. It works, but it feels laggy. The user clicks submit, waits a second, then sees the item appear. Not great.
Someone on a forum told me to generate the ID on the frontend before sending it to the server. I was confused — how can the frontend pick an ID if it doesn’t know what IDs already exist in the database? What if it picks one that’s already taken?
That’s the whole point of UUIDs. You generate a random one and the chances of it matching any existing ID are basically zero. Not “unlikely.” Mathematically almost impossible. There are more possible UUIDs than atoms on Earth. I didn’t believe that at first so I actually did the math — 2 to the power of 122 is a number so large it stops meaning anything to a human brain.
Okay but what does UUID actually mean
Universally Unique Identifier. 128 bits of data, usually shown as 32 hex characters with dashes in between. The one you care about is version 4 — that’s the fully random one. There are other versions that use timestamps or MAC addresses or hashes but honestly I’ve never needed any of them. v4 does the job.
Every programming language can generate them. JavaScript has crypto.randomUUID(), Python has uuid.uuid4(), PHP has Str::uuid() in Laravel. But sometimes you just need one quickly — pasting a test value into a config file or seeding a database — and opening a terminal to write one line of code feels like overkill. That’s why I added a UUID generator to this site. Click, copy, done.
Things I learned after using them for a while
Your user IDs leak information if they’re sequential. I never thought about this until a friend pointed it out. If you sign up for a service and your user ID is 4,831 — you now know they have roughly 4,831 users. With UUIDs, all you see is a random string. You learn nothing. For side projects this doesn’t matter but if you’re building something for a client it looks unprofessional to expose your user count in the URL.
File naming becomes easy. I used to let users upload files with their original names. Then two people uploaded “photo.jpg” and one overwrote the other. Lost someone’s profile picture. Took me an hour to figure out what happened. Now every upload gets renamed to a UUID. No collisions, no overwrites, problem gone forever.
Log tracing. I tag every API request with a UUID when it comes in. When something breaks and I’m scrolling through logs trying to find what happened, I search for that one UUID and every log line from that specific request shows up. Before I started doing this, debugging production issues was just… scrolling and hoping. Not a great system.
When I don’t use them
Small personal projects where I’m the only user — auto-increment is fine. A todo app, a notes app, anything where the data lives in one database and nobody’s going to inspect the IDs. Adding UUIDs to a project like that is overengineering.
Also, if you’re working with a database that doesn’t handle UUIDs well as primary keys (some older MySQL setups have performance issues with UUID indexes), you might want to stick with integers or use a UUID-to-binary conversion. I ran into this once — queries that were fast with integer IDs became noticeably slower with UUID strings. Switching to binary storage fixed it, but it was annoying to debug because I didn’t expect the ID format to affect query speed.
Questions people always ask me
“Can’t two people get the same UUID?” You’d have to generate billions per second for decades to even have a chance. Your computer’s random number generator failing is a more realistic concern, and even that basically doesn’t happen with modern systems.
“They’re so long though.” 36 characters as text, 16 bytes as binary. It’s more than an integer, sure. But unless you’re storing billions of rows and counting bytes, you won’t notice the difference. I’ve never had a project where UUID size was the actual bottleneck.
“Which version should I use?” Version 4. Random, no leaked info, works everywhere. I’ve read about v1, v3, v5, and v7 and I still just use v4 for everything. Keep it simple.
If you need a UUID right now — for a database entry, a test, a config file, whatever — the generator is right here. It does single and bulk generation. I use the bulk one when I’m seeding test data because generating 50 UUIDs one at a time is not how I want to spend my afternoon.