is of 18 digit ID really case insensitive?

Question

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?

Answer 1

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:

0019000001AWn2oAAD
0019000001awn2oAAA

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

0019000001AWn2o
0019000001awn2o

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.

Answer 2

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.

Answer 3

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.