UUID vs Short ID vs Slug

Not every identifier should be a UUID. Not every URL should use a readable slug. And not every short code is safe to treat as a secret.

Choosing the right identifier depends on the job: uniqueness, readability, stability, security, length, or search-friendliness.

Use the UUID Generator for unique identifiers. Use the Slug Generator when you need readable URL paths from titles or names. Use the Password Generator when you need a secret.

UUIDs

A UUID is designed to be globally unique. UUID v4 values look like this:

9f6f1b8a-5a4f-4c8f-9f4e-6a2d7b2f80a1

UUIDs are useful for:

• database records
• distributed systems
• public object IDs
• correlation IDs
• import/export references
• avoiding sequential ID exposure

They are not especially readable. That is fine for systems, but not ideal for URLs that humans need to understand or share.

Short IDs

Short IDs are compact identifiers, often used for invitation codes, share links, and temporary references:

a8K2pQ

They are easier to type and share than UUIDs, but they need careful design. A short ID has fewer possible combinations than a UUID. If it is public, make sure collisions are handled. If it protects access, do not assume short means secure.

Short IDs are good for convenience. They are not automatically good for secrets.

Slugs

Slugs are readable URL segments derived from text:

json-formatting-best-practices

Slugs are useful for:

• blog posts
• documentation pages
• category pages
• product pages
• SEO-friendly URLs

Slugs help people and search engines understand the page topic. But slugs are not guaranteed to be unique unless your system enforces uniqueness.

Two posts can have the same title. Two products can normalize to the same slug. A slug generator is only one part of the workflow; your CMS or database still needs collision handling.

Public Does Not Mean Secret

UUIDs, short IDs, and slugs are often visible in URLs. If a value appears in a URL, treat it as public.

Do not use a UUID or short ID as the only protection for private content. Access control should be handled by authentication, authorization, signed links, or properly generated secret tokens.

If the value must be secret, generate it like a secret. The Password Generator is a better model for unpredictable private values than a slug or ordinary ID.

Choosing by Use Case

Use a UUID when:

• systems need a unique ID
• records are created in multiple places
• readability is not important
• you want to avoid sequential database IDs in public APIs

Use a short ID when:

• the value must be typed or shared
• the lifetime is limited
• collisions can be checked
• the code is not the only security control

Use a slug when:

• the URL should be readable
• the page has a title
• SEO and user clarity matter
• you can handle duplicate slugs

Comparison Table

This distinction helps avoid a common design mistake: using one string format for every job. A UUID can identify a record, a slug can describe a page, and a secret token can authorize a temporary action.

Combining Identifiers

Many systems combine a readable slug with a stable ID:

/blog/json-formatting-best-practices-9f6f1b8a

This gives humans a useful URL while the system still has a stable unique reference. Another pattern is to use the slug for display and the database ID internally.

Collision Handling

Every identifier system needs a plan for duplicates. UUID collisions are extremely unlikely in normal use, but short IDs and slugs need explicit checks.

For slugs, a CMS might generate:

json-formatting-best-practices
json-formatting-best-practices-2
json-formatting-best-practices-3

For short IDs, the application should generate a candidate, check whether it already exists, and retry if needed. The shorter the ID, the more important that retry logic becomes.

Do not rely on visual uniqueness. Two strings can look different to developers but confusing to users, especially if they mix 0 and O, 1 and l, or uppercase and lowercase letters.

SEO and URL Stability

Slugs are visible in search results, browser history, shared links, and documentation. A clean slug can reinforce the page topic:

/blog/css-minifier-guide/

That is easier to understand than:

/blog/post?id=839201/

However, changing slugs after publication can break links and reset accumulated signals if redirects are missing. If you update a title later, do not automatically change the slug unless the old URL redirects cleanly to the new one.

The Slug Generator is useful for creating consistent candidates, but the final publishing workflow should also check duplicates, redirects, and internal links.

Security Notes

A short public ID is not the same thing as a permission check. For example, this kind of URL may be convenient:

/share/a8K2pQ

But if anyone with the link can see private data, the application still needs expiration, rate limiting, access controls, or signed tokens depending on the risk.

UUIDs are also not secret. They are harder to guess than sequential numbers, but they should not replace authorization.

Bottom Line

UUIDs are for uniqueness. Short IDs are for compact sharing. Slugs are for readable URLs. Secret tokens are a separate category.

Pick the identifier based on the risk and workflow, not just the shape of the string.

Related Guides

• UUID generator guide for developers explains when UUIDs are the right default identifier.
• Slug generator guide focuses on readable, stable URLs for public pages.
• Browse related utilities in the Generators collection.