What is a Short UUID Generator
A UUID is fixed at 16 bytes, but its usual spelling is wasteful: 36 characters, four of which are hyphens and 32 of which use only 16 of the symbols a URL can carry. Re-encoding those same bytes in base64url produces 22 characters — a 39% saving with no loss at all, and the result survives being put in a query string, a filename or a cookie without escaping.
Entropy is the part you can choose. 8 bytes give 64 bits, 12 bytes give 96 and the full 16 bytes keep the 128 bits of a UUID. The birthday bound makes the trade-off concrete: with 64 bits, a collision becomes plausible after roughly a few hundred million values, while 96 bits stay safe for any realistic table and 128 bits are effectively beyond reach.
What you give up is structure. A compressed UUID has no version nibble and no variant bits, so it is no longer self-describing — a database cannot extract a timestamp from it, and a validator cannot say which version it is. If you need that metadata, use a real v4 or v7; if you only need a compact, opaque key, the short form is the better fit.
How to
- Set how many identifiers you need.
- Choose the bytes of randomness: 8 bytes for 11 characters, 12 for 16, or 16 for a 22-character compressed UUID.
- Press Generate, then copy a single value or export the whole batch.
Use cases
- Short links and files where a 36-character name is awkward to read aloud or paste.
- Compact database keys when a 22-character text column is cheaper than a 36-character one.
- Cache keys and request ids, where the value only has to be unique, not parseable.
Compare Short UUID Generator with other formats
| Option | When to use |
|---|---|
Canonical UUID | 36 characters, 128 bits, self-describing (version and variant included). |
Base64url UUID | 22 characters, 128 bits, no metadata — the lossless compression of the same value. |
12-byte random | 16 characters, 96 bits, enough for very large tables. |
8-byte random | 11 characters, 64 bits — fine for caches, risky as a permanent primary key. |
Code examples
JavaScript
// Node 18+ / modern browsers: 16 bytes -> 22 URL-safe characters
const bytes = crypto.getRandomValues(new Uint8Array(16));
const id = Buffer.from(bytes).toString('base64url'); // 22 chars
// Browser-only variant
const id2 = btoa(String.fromCharCode(...bytes))
.replace(/\+/g, '-').replace(/\//g, '_').replace(/=+$/, '');
Python
import os, base64
# 16 bytes -> 22 characters (no padding), URL-safe
id_ = base64.urlsafe_b64encode(os.urandom(16)).rstrip(b'=').decode()
# 8 bytes -> 11 characters
short = base64.urlsafe_b64encode(os.urandom(8)).rstrip(b'=').decode()
# Decoding a compressed UUID back to canonical form
import uuid
raw = base64.urlsafe_b64decode(id_ + '==')
print(uuid.UUID(bytes=raw))
Frequently asked questions
Are short IDs still unique?
They are as unique as the bits you give them. 16 bytes carry exactly the same 128 bits as a UUID, so the collision probability is identical. Dropping to 8 bytes cuts the space to 264, where a collision becomes likely after a few hundred million values — plenty for a cache, not enough for a permanent ledger.
Can I turn a short ID back into a UUID?
Yes, if you used 16 bytes: decode the base64url and you have the original 16 bytes, which is a valid UUID in binary form. With 8 or 12 bytes there is nothing to restore — those identifiers never contained the missing bits.
Should I use this as a database primary key?
Only if the column is indexed as text and you do not need the database to read a timestamp out of the key. If ordering matters, a time-ordered UUID v7 stored in a native uuid column is usually the better answer.