The UX of UUIDs

Original Article ↗ Hacker News Discussion ↗

UUIDs are praised for enabling decentralized, almost-collision-free identifiers, but engineers highlight that their standard 128‑bit, hyphenated hex format is awkward for humans to read, copy, speak, or transcribe safely. Commenters explore alternatives and refinements—such as UUIDv7, ULID, TypeID, base32/58 encodings, prefixes, and checksums—to improve usability in URLs, logs, and customer support without sacrificing randomness or database performance. A recurring theme is separating internal primary keys from user-facing IDs, and carefully weighing UX gains against added complexity or nonstandard transformations.

Uniqueness and collision risk

  • Several comments stress that UUIDs are only “unique” once a system prevents reuse (e.g., via a DB uniqueness constraint).
  • Others reply that properly generated 128‑bit random UUIDs have astronomically low collision probability; practical risks come more from bugs or hardware faults than true collisions.
  • The birthday paradox is invoked to correct an overoptimistic collision estimate in an extreme thought experiment.

Client-side generation and security

  • UUIDs are praised for distributed, coordination‑free ID generation.
  • However, if clients can choose IDs, malicious users can deliberately collide with existing IDs to access others’ data.
  • Suggested mitigations: server‑side uniqueness checks, or server‑generated IDs, unless offline/latency-hiding use cases require client-side generation.

UUIDs as database primary keys

  • Critics note performance issues with random UUIDs as clustered primary keys (e.g., page splits, WAL growth).
  • Alternatives: monotonic integers (bigserial), k‑sortable IDs, or UUIDv7.
  • Others argue UUID PKs greatly simplify distributed/offline data merging, even if performance is worse in a single central DB.

Alternative ID formats (ULID, TypeID, etc.)

  • Multiple alternatives are mentioned: TypeID, ULID, KSUID, CUID, shortUUID, snowflake‑style IDs, base24/base32 schemes, etc.
  • Debates:
    • Some say ULID should be deprecated in favor of UUIDv7; others claim ULID still has advantages (more precise timestamp, friendlier string form).
    • TypeID is seen as a nice wrapper over UUIDv7 with type prefixes; critics worry type‑coupled IDs can become brittle as concepts change.

Human UX: copying, reading, speaking

  • Hyphens break “double‑click to select” behavior; proposals include removing hyphens or using underscores or other separators.
  • Counters argue separators aid manual transcription and chunking; removing them hurts rare but important manual tasks.
  • CSS user-select: all and explicit copy buttons are recommended where possible, but don’t help in terminals, DB clients, or address bars.
  • Some note that most users copy‑paste rather than type IDs, so readability tweaks may have limited benefit.

Encodings, alphabets, and swear words

  • Base58 is favored for omitting ambiguous characters (I, l, O), but criticized as slower and case‑sensitive.
  • Hex/base16 and Crockford’s base32 are popular for simplicity and case‑insensitivity.
  • Marketing concerns about accidental swear words arise; suggested mitigations include restricted alphabets or rerolling offending IDs.