SF ID Converter
Convert 15↔18 char Salesforce IDs, detect sObject types by prefix, and build SOQL WHERE IN clauses.
About the Salesforce ID Converter
Convert Salesforce 15-character case-sensitive IDs to 18-character case-insensitive IDs, detect sObject types by prefix, and generate SOQL WHERE IN clauses — all in bulk, 100% client-side.
About Salesforce ID Converter
Convert between the 15-character (case-sensitive) and 18-character (case-insensitive) forms of a Salesforce record ID, in both directions, plus identify the object type from the 3-character key prefix. Built for the moment you're staring at a CSV export, an exception trace, or a URL fragment and need to know whether two IDs refer to the same record.
What this tool does
- 15 → 18 — appends the case-insensitive checksum so the ID survives systems that mangle case.
- 18 → 15 — strips the checksum and returns the canonical case-sensitive form.
- Object detection — reads the first three characters and names the standard object (or marks it as custom).
- Bulk mode — paste a list, get a list back, ready for SOQL or CSV.
Why are Salesforce IDs case-insensitive in the 18-char form?
The original Salesforce ID is a 15-character base-62 string that mixes upper and lower case — 001A0000005wTFA and 001a0000005wtfa are different records. That works inside Salesforce, but the moment an ID passes through a system that doesn't preserve case — Excel, certain databases, URL routers that lowercase paths, file systems that compare case-insensitively — two distinct IDs can collapse into one and the wrong record gets touched. The 18-character form solves this by appending a 3-character checksum that encodes the case pattern of the first 15 characters. Two IDs that differ only in case produce different checksums, so the 18-character form can be compared case-insensitively without ambiguity. Salesforce APIs accept both lengths interchangeably; treat 18 as the safe interchange format and 15 as the internal form.
Pipeline
Output from this tool can be sent directly to:
- SOQL Query Builder — drop converted IDs into an
IN (...)clause to query records. - Field Analyzer — inspect the schema of the object identified by the key prefix.
Privacy
IDs are never sent anywhere. Conversion is a few lines of arithmetic running in your browser. Read our privacy policy.
Frequently asked
- What's the algorithm?
- Salesforce 18-character IDs append a 3-character checksum to the original 15-character ID. The checksum encodes the case of the first 15 characters in groups of five: each group of 5 chars is read as 5 bits (1 if the char is uppercase, 0 otherwise), giving a number 0–31, which is then mapped to a single character from the table `ABCDEFGHIJKLMNOPQRSTUVWXYZ012345`. Three groups of five = three checksum characters. The result is that two IDs differing only in case map to different 18-character IDs, so the case-insensitive comparison works correctly.
- What does the 3-character prefix mean?
- The first three characters identify the object type (the key prefix). `001` is Account, `003` is Contact, `006` is Opportunity, `00Q` is Lead, `500` is Case, `a00`–`a9Z` ranges are typically custom objects, and so on. Standard prefixes are documented; for custom objects, the prefix is assigned at object creation and is org-specific. You can use the prefix to validate that an ID belongs to the object you expect before issuing a SOQL query.
- Are 15-char IDs ever wrong?
- They're never wrong, but they're case-sensitive — so any system that lowercases or uppercases them (URL parameters in some routers, Excel autocorrect, case-insensitive databases) can corrupt them. The 18-character form was introduced specifically to survive case-insensitive systems. Inside Salesforce APIs, both lengths refer to the same record. As a rule, store the 18-character form in external systems and use the 15-character form only inside Apex/SOQL where you know case will be preserved.
- Can I bulk-convert?
- Yes — paste a newline- or comma-separated list of 15-character IDs and the tool will return the 18-character form for each, plus the detected object prefix. Conversion is purely arithmetic so it scales to thousands of IDs without latency. Output is suitable for pasting back into a CSV column or a SOQL `IN (...)` clause.