Why Salesforce IDs come in two sizes (and how Excel forced the issue)

Every Salesforce record has two IDs that point at it: a 15-character case-sensitive form and an 18-character case-insensitive form. The two are different lengths of the same address. Most admins know they exist; far fewer know why they exist. The answer is one of the cleverer pieces of small-scale architecture in commercial SaaS, and it’s worth understanding because the pattern shows up elsewhere too.

1. The 15-character design was a deliberate choice

Salesforce launched in 1999 on Oracle Database. Like a lot of late-90s SaaS architecture, the team wanted record identifiers that were:

• Globally unique across every tenant in the multi-tenant org
• Short enough to fit in URLs, integrations, and the sales reps’ tab-delimited exports
• Fast to generate without coordination overhead

What they landed on: 15-character alphanumeric IDs in three parts. The first three characters identify the object type (the prefix — 001 for Account, 003 for Contact, 00Q for Lead). The next two characters identify the pod or instance. The last ten characters are the unique sequence within that prefix/pod combination.

The crucial detail: the alphabet is case-sensitive. The 15-character ID uses all 62 alphanumeric characters — uppercase, lowercase, and digits. That seemingly tiny choice buys you roughly twenty-four orders of magnitude more namespace than the same 15 characters in a case-insensitive base-36 alphabet would. 62¹⁵ is about 7.6 × 10²⁶. 36¹⁵ is about 2.2 × 10²³. Case sensitivity isn’t window dressing — it’s the difference between “plenty of room forever” and “we’ll need to lengthen the ID in a decade.”

2. The Excel problem

The trouble showed up immediately at the boundary of Salesforce and the rest of the operations stack. Salesforce’s native UI, its APIs, and its database treat the 15-character ID as case-sensitive, exactly as designed. Everything downstream — the systems Salesforce data has to live alongside in the real world — very often does not.

The canonical offender is Excel. Excel’s string comparisons (VLOOKUP, MATCH, =A1=B1) are case-insensitive. Save a Salesforce export to a CSV, open it in Excel, do a join, and you’ll merge records that aren’t the same record. Pivot tables fold case. Sorting can fold case. If you re-import the result into Salesforce, the loader will look up against whatever case Excel happened to keep, and you’ll quietly update the wrong rows.

Excel is the household name, but the problem is structural and shows up everywhere case folding is the default:

• SQL identifiers in Oracle, the very database Salesforce sits on, fold to uppercase by default unless quoted. The data values in columns are case-sensitive; the schema is not. A whole class of legacy mainframe and ERP integrations carry the same identifier-folding habit.
• Filesystems on Windows and on default macOS volumes are case-insensitive. Naming files after Salesforce IDs — a common backup pattern — collides records.
• Database collations like SQL_Latin1_General_CP1_CI_AS in SQL Server (the “CI” is “case-insensitive”) treat abc and ABC as the same key.
• Email and tracking systems routinely normalize case for deduplication.

So the constraint Salesforce faced was: keep the 15-character ID case-sensitive, because that’s how the namespace math works — but make it possible for case-folding downstream tools to handle the same record without losing information.

3. The 18-character fix

The solution is the part that’s actually clever. Salesforce defined a deterministic 3-character suffix you can append to any 15-character ID. The suffix is computed locally from the ID itself — no API call needed — and it encodes which of the first 15 characters were originally uppercase.

The algorithm fits on a napkin. Take the 15-character ID. Split it into three chunks of 5 characters each. For each chunk, build a 5-bit number where each bit is 1 if the character at that position is uppercase A–Z and 0 if it’s anything else (a digit or a lowercase letter — both count the same way). The resulting number is in the range 0–31, which is exactly the size of the alphabet ABCDEFGHIJKLMNOPQRSTUVWXYZ012345. Pick the matching character. Do that three times. Concatenate. You have the suffix.

Append the suffix to the original 15 characters and you have the 18-character ID. The whole thing took less than half a page in the Salesforce internals.

What makes this clever is what the algorithm guarantees:

• The 18-character form is deterministic from the 15-character form. No state is needed. No lookup table. Two different systems can compute the same 18-character ID for the same 15-character ID without ever talking to each other.
• The 18-character form is case-insensitive-safe. If a case-folding system uppercases your ID, the suffix characters (which were already uppercase A–Z and 0–5) are unchanged. The prefix loses case, sure — but the suffix still knows what case the prefix should have been.
• The 15-character form is never invalidated. Old URLs, old exports, old integration field-mappings still work. The 18-character form is a strict superset.

This is a textbook compatibility extension. The new format extends the old without breaking it; the math is local and deterministic; and the property the new format adds (round-tripping through case-folding tools) is exactly the property the old format was missing.

4. The reverse trick: case recovery

Once you understand the suffix is a case mask, you get a feature for free. If a case-folding system has turned your 18-character ID into an all-uppercase string — 006HP00002KQL3RIAV instead of 006Hp00002KqL3RIAV — you can still recover the original mixed case. The suffix is unchanged (it was always uppercase), and it tells you exactly which characters in the first 15 should be uppercase.

This is what our Salesforce ID converter does when you paste a mangled 18-character ID. We decode the suffix, restore the original case to the prefix, and hand you back the correct form. Open-source implementations in JavaScript and Ruby have done this for years; it’s a well-understood trick once you see the encoding for what it is.

The catch worth flagging: case recovery works only for 18-character IDs. If you only have a 15-character ID that’s been case-mangled, there’s no checksum to fall back on — the case information is genuinely gone, and your only option is to ask Salesforce for the canonical form.

5. Why this matters architecturally

Three things are worth pulling out of this story:

Case-sensitivity is a deliberate namespace decision, not an oversight. The 24-orders-of-magnitude difference between case-sensitive base-62 and case-insensitive base-36 is real engineering value. When you’re designing identifiers for a system that’ll outlive its creators, you do not give those bits away casually.

Cross-system compatibility deserves design, not a workaround. Salesforce could have shipped a longer case-insensitive form and migrated everyone. They didn’t — they shipped a backward-compatible extension that fixed the downstream-tool problem without forcing any change on existing integrations. That pattern (extend the canonical form with a deterministic, case-safe suffix) shows up in other places too: JSON Web Tokens, Bitcoin addresses, IBAN bank account numbers. All three have versions where a checksum or a base-shift makes the value round-trippable through case-folding or character-confusing systems.

Architecture decisions cast shadows for decades. The 18-character form was added in the early 2000s. Twenty-five years later, every Salesforce integration in the world has to decide which form to store, and the answer is almost always “the 18-character one, because we don’t know what downstream system will touch it.” Salesforce got that decision right. Most platforms don’t.

What to do this week

If you have an integration that’s storing 15-character Salesforce IDs in an external system, convert them to 18-character before storage. Future you will thank present you the first time someone does a case-folding migration on the downstream side. If you’ve already been bitten — you have records where the case has been mangled but you still have the original 18-character IDs — our ID converter will recover the correct case for you.

For more on the design choices behind clean Salesforce orgs, see Salesforce Well-Architected: trust first, ease second, adaptability third.