Every Salesforce record has a unique identifier called a Salesforce ID. But Salesforce IDs come in two formats: 15‑digit and 18‑digit. This often causes confusion in development, integrations, automation, and data processing. As of now, this distinction still matters and knowing when and how to handle each format correctly is key to avoiding bugs, mismatches, and integration failures.
What Are 15‑Digit and 18‑Digit Salesforce IDs?
15‑Digit IDs
- These are the original format used by Salesforce.
- They are case‑sensitive: uppercase and lowercase letters matter for uniqueness.
- Commonly seen inside the Salesforce UI (e.g., record URLs in Classic, or exported reports without augmentation).
- Example:
001A0000009XYZq.
18‑Digit IDs
- This is an extended format that includes an additional 3‑character checksum appended to the 15 digits.
- Designed to make the ID case‑insensitive for external systems (e.g., Excel, databases).
- The first 15 characters are identical to the 15‑digit ID; the extra 3 characters encode case information.
- This format is default in most API responses and integration tools like Data Loader.
- Example:
001A0000009XYZqABC.
When Does Salesforce Return 15 vs 18 Characters?
In the Salesforce UI
- Classic UI and standard reports often show 15‑digit IDs by default.
- Even Visualforce merging
{!Account.Id}sometimes returns the 15‑digit ID.
In the API
- Most API calls (REST/SOAP/Bulk/Tooling) return 18‑digit IDs by default.
- The API accepts both 15‑digit and 18‑digit forms on insert/update, but returns 18 digits.
In Salesforce Lightning
- Lightning URLs and platform components increasingly show the 18‑digit ID by default.
In Reporting
- Standard report exports typically include the 15‑digit ID unless you explicitly include an 18‑digit formula field.
Why the Two Formats Exist
Salesforce originally used 15‑digit IDs internally, but that design has one problem: external systems often treat text as case‑insensitive. For instance:
- Excel’s
VLOOKUPtreats001ABC...and001abc...as equal. - SQL databases might not preserve letter case.
This can cause duplicate mismatches or bad joins when ID uniqueness is assumed. To solve that, Salesforce introduced an 18‑digit format with a suffix that encodes case info, making IDs unique even in case‑insensitive systems.
Developer & Integration Best Practices
1. Always Normalize to 18‑Digit for Comparisons
When you compare IDs in code or integrate with external systems, normalize to 18 digits:
- In Apex,
Idfields queried via SOQL are already 18 digits. - For string comparisons, always compare normalized 18‑digit forms.
- If you have a 15‑digit ID (from a report, UI paste, etc.), convert it before matching.
2. Use CASESAFEID() in Formula Where Appropriate
Salesforce provides a built‑in function:
CASESAFEID(Id)This returns the 18‑digit version of any 15‑digit ID. Use this in:
- Formula fields for reports
- Flow formulas
- Validation rules
- Default values in automations
This ensures all outputs are in a consistent, integration‑safe form.
3. Handling IDs in Excel or Data Tools
If a report export has 15‑digit IDs:
- Add a formula field with
CASESAFEID()so exports include 18‑digit IDs. - Or use conversion tools/extensions that generate an 18‑digit ID from a 15‑digit one before doing joins or lookups.
4. Integration & Middleware
In ETL/ELT, middleware, and APIs:
- Ensure ID fields are treated as case‑insensitive keys.
- If a connected system expects case insensitivity, use 18‑digit IDs to avoid mismatches.
- When receiving IDs from external systems, always expect 18 digits; if you see 15, convert it.
