18 character IDs are case sensitive

This post is a bit embarrassing to write, as I have to admit that I have been totally misunderstanding 18 character Ids for just about as long as I have known about them.

The title spells it out: 18 character IDs are case sensitive, period. Even though the definition of CaseSafeID on the help and training site states:

This formula replaces the 15-character Id with the 18-character, case-insensitive ID.

and even though there are help and training articles that call the 18 character Id ‘not case sensitive’ and blog posts that say

The 18-character ID is not case-sensitive. In other words, 001C000000O4OOIIA2 and 001c000000o4ooiia2 both refer to the same record.

– this simply is not the case (ha).

The 18 character Id is unique, and as such can be compared by tools, like excel’s vlookup function, that are not case sensitive.

But if you change the case on an 18 character Id, it is no longer valid.

The reason for this is because the three letters that you add to the 15 character Id to make an 18 character Id are a function of the case of the 15 character Id.

so:

0034000001lrbM5 ==> 0034000001lrbM5AAI
0034000001lRBM5 ==> 0034000001lRBM5AAO

and 0034000001lRBM5AAI is invalid.

You simply could never have a result like 0034000001lRBM5AAI - it simply does not compute. Its the equivalent of 1 + 1 = 99. The 15 character Id 0034000001lRBM5 converts to 0034000001lRBM5AAO, and if you flip the case on any of the letters in the 18 character Id, its no longer valid.

And that is that. 2016 will now be remembered as the year that I learned what an 18 character Id actually is.

Update - thanks to Bonny Hinners and Douglas Ayers, I’ve realized that with any 18 character ID, even if the case is modified, you can get back the correct id! This github repo has some javascript to make that happen, and a great explanation of how it works. Glad someone wrote a function for it as I would not want to try going through it manually more than once, if that.