Salesforce ID converter
Paste any number of 15-character Salesforce record IDs — or mix in 18-character ones, even all-uppercase ones that lost their case in Excel. We’ll convert, detect the object type, validate checksums, and recover the original mixed case when the suffix lets us.
100% client-side. Nothing uploaded.
Paste IDs
Results
Paste some IDs on the left and the converted results will appear here.
What this tool is.
And what it’s for.
What this is
Every Salesforce record has an ID. Historically, that ID was a 15-character, case-sensitive string. Modern Salesforce returns an 18-character version of the same ID that encodes the case of the first 15 characters in a 3-character checksum suffix. This tool converts back and forth in bulk, detects the object type from the prefix, and validates checksums on 18-character inputs.
How the conversion works
The algorithm is small enough to fit on a napkin. Split the 15-character ID into three 5-character chunks. 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 otherwise (digits and lowercase letters both count as 0). The resulting number (0–31) is the index into the alphabet ABCDEFGHIJKLMNOPQRSTUVWXYZ012345. Concatenate the three resulting characters — that’s your suffix. Append it to the 15-character ID and you have the 18-character form.
Because the suffix encodes case, two 15-character IDs that look identical but differ only in case will produce different 18-character IDs. That’s exactly why the 18-character form is safe to round-trip through tools that mangle case — like Excel.
Case recovery: the reverse trick
The suffix is also a bit-mask in the other direction. If a case-folding system has turned your 18-character ID into an all-uppercase string, the suffix itself is unchanged (it was always uppercase A–Z plus digits 0–5), so it still encodes which characters in the first 15 were originally uppercase. This tool reverses the encoding automatically: paste an all-caps 18-character ID, get the original mixed-case form back. We mark these results as case recovered so you know we corrected your input rather than accepting it as-is. See our writeup on why Salesforce IDs are case-sensitive at all.
The catch: case recovery works only when you have the full 18-character ID. If you only have a case-mangled 15-character ID, the case information has been irrecoverably lost — you’ll need to query Salesforce for the canonical form.
Why a Salesforce admin cares
- Data Loader / Bulk API exports give you 15-character IDs. If you transform them in Excel and re-upload, you can hit the wrong record because Excel mangles case.
- Reports show 15-character IDs in the UI but Salesforce URLs accept both lengths. Pasting a copied ID into a chat tool or email can lose case.
- Third-party integrations (Workato, Zapier, MuleSoft, marketing platforms) sometimes assume case-insensitivity. Storing the 18-character form upstream prevents an entire class of “wrong record” bugs.
- Cross-system reconciliation. When you’re comparing IDs across Salesforce and an external database, both sides should hold the 18-character form so equality checks aren’t fooled by case.
- Apex string literals. Hardcoded 15-character IDs in Apex unit tests are a known footgun. Convert them on the way in.
Why hire blufyre.com
We built this tool because we kept needing it ourselves. If you’re running a Salesforce org where 15-vs-18 has caused a real incident — a migration that mapped to the wrong record, an integration that fan-outs to the wrong contact, a workflow that fires for the wrong owner — that’s usually a symptom of a deeper architectural gap. We’re a small boutique Salesforce consultancy with senior, certified consultants and Ivy League and Oxbridge academic credentials. We do implementations, integrations, and custom Apex/LWC work where the architecture is decided on purpose, not inherited from someone’s sandbox.
Start a conversationCommon questions.
- Why do Salesforce IDs come in two lengths?
- Salesforce historically stored object IDs as 15 case-sensitive characters. The 18-character form is the same ID with a 3-character checksum suffix that encodes the case of the first 15 characters. The 18-character ID is case-INsensitive, which is what most systems outside Salesforce need.
- Where do I see 15-character vs 18-character IDs?
- Reports, the Data Loader, the Bulk API, and most exported CSVs return 15-character IDs by default. The Lightning UI, REST API responses, and most modern integrations return 18-character. If you've ever pasted an ID from Excel back into a Salesforce URL and gotten the wrong record, that's the 15-vs-18 case sensitivity problem.
- Is the algorithm reversible?
- More than you might expect. Going from 15 to 18 is deterministic. Going the other way is trivial: chop off the last 3 characters. The clever part: if all you have is an all-uppercase 18-character ID (because Excel or a database with case-insensitive collation mangled it), you can still recover the original mixed case — the suffix itself was always uppercase A–Z and 0–5, so it survives case folding, and it encodes which of the first 15 characters were originally uppercase. This tool does that recovery automatically.
- What happens if I paste an all-uppercase 18-character ID?
- We recover the original mixed case using the suffix as the source of truth, and mark the result as 'Case recovered' so you can see we corrected it. The recovered 18-character form is what you should use going forward — paste it back into URLs, store it in upstream systems, and the case-sensitivity problem is solved.
- What's an 'object prefix'?
- The first three characters of every Salesforce ID identify the object type. 001 is Account, 003 is Contact, 005 is User, 006 is Opportunity, 00Q is Lead, and so on. Custom objects start at a01 and increment per org. We display the type when we recognize the prefix.
- Does this tool send my IDs anywhere?
- No. Everything runs in your browser as static JavaScript. There is no backend, no logging, no analytics on this page. Salesforce record IDs aren't secret, but they aren't your data to give away either.