Introduction

In .NET, a “short unique identifier” usually means one of two things: a compact encoding of a Guid, or a different ID scheme entirely such as a random token, snowflake-style ID, or database-generated value. The correct choice depends on whether you need global uniqueness, sortability, URL-friendliness, or very short length.

The first design question is not “how do I make it shorter?” It is “what uniqueness guarantees do I actually need?”

Option 1: Encode a Guid More Compactly

A Guid is 128 bits whether you print it as 36 characters or not. If you want the same uniqueness with a shorter string, encode the bytes with URL-safe Base64.

1using System;
2
3class Program
4{
5    static string ToShortGuid(Guid guid)
6    {
7        return Convert.ToBase64String(guid.ToByteArray())
8            .Replace("/", "_")
9            .Replace("+", "-")
10            .TrimEnd('=');
11    }
12
13    static void Main()
14    {
15        Guid id = Guid.NewGuid();
16        string shortId = ToShortGuid(id);
17
18        Console.WriteLine(id);
19        Console.WriteLine(shortId);
20    }
21}

This often gives a 22-character string instead of the usual 36-character GUID text. The underlying uniqueness is unchanged because you are only changing the representation.

Decode It Back When Needed

If you need reversible storage or debugging, add the reverse operation.

1using System;
2
3class Program
4{
5    static Guid FromShortGuid(string shortGuid)
6    {
7        string padded = shortGuid.Replace("_", "/").Replace("-", "+");
8        switch (padded.Length % 4)
9        {
10            case 2: padded += "=="; break;
11            case 3: padded += "="; break;
12        }
13        return new Guid(Convert.FromBase64String(padded));
14    }
15}

That makes the format practical when you want short IDs in URLs but still want to recover the original Guid later.

Option 2: Use a Different Identifier Scheme

Sometimes a 22-character short GUID is still too long. If you truly need fewer characters, you are usually no longer talking about “the same as a GUID but shorter.” You are trading off something:

• collision probability
• decentralization
• sortability
• predictability
• reversibility

For example, a random 8-character token is easy to generate, but it does not give the same collision safety as a full 128-bit identifier.

1using System;
2using System.Linq;
3
4class Program
5{
6    static readonly char[] Alphabet = "abcdefghijklmnopqrstuvwxyz0123456789".ToCharArray();
7
8    static string RandomToken(int length)
9    {
10        var random = new Random();
11        return new string(Enumerable.Range(0, length)
12            .Select(_ => Alphabet[random.Next(Alphabet.Length)])
13            .ToArray());
14    }
15}

This may be fine for invitation codes or temporary references, but not for high-scale globally unique primary keys.

Pick the Identifier Based on the Use Case

A reasonable rule of thumb:

• use Guid or short-encoded Guid for general distributed uniqueness
• use database integers when local monotonic IDs are enough
• use ULID-style or similar schemes when ordering by creation time matters
• use short random tokens when human readability matters more than strong uniqueness guarantees

The wrong design is usually choosing a short random string because it “looks nicer,” then discovering collisions later.

Common Pitfalls

• Assuming a shorter string automatically preserves GUID-level uniqueness.
• Using Guid.NewGuid().ToString().Substring(...), which destroys uniqueness guarantees arbitrarily.
• Forgetting URL-safe replacements when the short ID will appear in routes or query strings.
• Choosing a very short random token without estimating collision risk at your expected scale.
• Mixing multiple ID schemes in one system without documenting what each one means.

Summary

• In .NET, the safest short unique ID is often a URL-safe Base64 encoding of a Guid.
• That makes the text shorter without changing the underlying 128-bit uniqueness.
• If you need fewer characters than that, you are choosing a different ID scheme with different tradeoffs.
• Never truncate GUID strings blindly and assume the result is still safe.
• Pick identifier length and format based on collision tolerance, ordering needs, and where the ID will be used.