As per documentation(or should i say popular belief ... as i did not find exact documentation link) 18 digits are case insensitive and 15 digit ids are case sensitive.

In fact many site blogs says that 18 digits was invented to ignore case of characters in id field.

When I tested it in developer console and workbench it did not work as expected.

For ex, my account id is '0019000001AWn2o'. In 18 digit format it is '0019000001AWn2oAAD'

Now, if we change case of any characters in 18 digit id then also system should work. (At least that is what interpretation about case insensitive ID)

But to my surprise non of following ids work in SOQL ,URL or from API

  • 0019000001AWn2oAAd
  • 0019000001aWn2oAAD
  • 0019000001AWn2OAAD

So, what it seems like the popular belief is wrong that 18 digits are case insensitive. But last 3 digit just act as check sum for validation.

I know that we can decode the 18 digit id and get the original 15 digit id but i was expecting that platform should have handle it when I pass 18 digit id.

Am i missing something here?


3 Answers 3


The parity bits are meant to help systems that ignore case sensitivity to properly find records where the short Ids differ only by case. For example, SOSL can't tell between case, so if you're logging Ids into a text field, the long Id will correctly find just the records you want.

It does not mean you can, or should, freely modify an Id's case. It simply means that systems that can't tell between lowercase and uppercase, usually as a convenience to users, won't match up records incorrectly.

In general, you should always prefer to use the long Id when possible, as it increases interoperability with various systems.

As an example, consider these two ID values:


If you were to use just the 15-character form, they then look like this:


If you try to compare them in Excel, you get an "unexpected" result:

="0019000001AWn2o"="0019000001awn2o"  (TRUE)

This makes normal VLOOKUP functions fail, because Excel doesn't normally care about case sensitivity.

However, using the long version:

="0019000001AWn2oAAD"="0019000001awn2oAAA"  (FALSE)

Solves the case insensitivity issue. This allows the external system to properly match up records when it considers uppercase and lowercase to be an equal value.

  • So in other words 18 digit id is also sensitive about case ? Jul 6, 2016 at 8:05
  • and if that is true then how can i integrate with non case sensitive DB/systems? Jul 6, 2016 at 11:15
  • @AtulRajguru9 I've added an edit. The three extra characters cause two similar 15-character ID values to become unique in case insensitive environments. Salesforce always expects the ID values to be of the same case as they were generated, but this allows case insensitive systems to see values uniquely as salesforce does.
    – sfdcfox
    Jul 6, 2016 at 17:23
  • 3
    Thank you sfdcfox, it makes sense now. I just wish they had better documentation around it. many developers like me still lives under the impression that 18 char ID is truly case insensitive and expect platform to handle changes in case. Jul 7, 2016 at 3:55

The 18-digit Id is only case-insensitive in regards to uniqueness. It will not work for queries/urls/etc. without proper casing.

You're not the first one to experience this issue. As far as I can tell, @DanielBallinger was the first to explain how to fix the casing of an Id here (via C#) and there are a couple ports to Apex here.


18 digit case-insensitive version which is referenced through the API.

The last 3 digits of the 18 digit ID are a checksum of the capitalizations of the first 15 characters, this ID length was created as a workaround to legacy systems which were not compatible with case-sensitive IDs. The API will accept the 15 digit ID as input but will always return the 18 digit ID.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .