UUID UUID Generator

Free · No signup · No install

Short UUID Generator

A canonical UUID costs 36 characters. When that is too long for a URL, a filename or an index, this tool packs the same 128 bits into 22 URL-safe characters — or gives you a shorter ID when UUID-grade entropy would be overkill.

  • 22-character base64url UUID
  • Also 11 and 16 characters
  • URL-safe and copy-ready

Short UUID Generator

Short
Between 1 and 1000.

Result 0

    Generated locally with the Web Crypto API — nothing leaves your browser. Shortcut: Ctrl + Enter — Regenerated

    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

    1. Set how many identifiers you need.
    2. Choose the bytes of randomness: 8 bytes for 11 characters, 12 for 16, or 16 for a 22-character compressed UUID.
    3. 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

    OptionWhen to use
    Canonical UUID36 characters, 128 bits, self-describing (version and variant included).
    Base64url UUID22 characters, 128 bits, no metadata — the lossless compression of the same value.
    12-byte random16 characters, 96 bits, enough for very large tables.
    8-byte random11 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.