function readOnly(count){ }
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
+ Start a Discussion

Difference Between 15 and 18 Digit Record Id

Hi Experts,
     I would like to know the exact difference between 15 and 18 digits record id. Most of us say, 15 digit(case sensitive) and 18 digit(case insensitive).

Let's consider a small example,
While if you query record from Developer Console you will get 18 digit record id. Consider the below retrieved 18 digit id,

001i000001AWbWuGTA(Retrieved from query)

If 18 digit case insensitive means,

001i000001AWbWugta (this id same to the above retrieved ID)? If yes, then if you queried record with this id means, you will get no result or no rows found..!

So if both 15 and 18 are unique means what is the real time use and difference between these two ID's.

Thanks in advance..!
Amit Chaudhary 8Amit Chaudhary 8
In API versions prior to 2.0, the ID of a record is always a 15-character case-sensitive ID and should not be compared in a case-insensitive manner

NOTE: This article doesn't indicate that the 18 character reference IDs are *not* case sensitive

Please check below link (

Converting 15 digit Salesforce opportunity ID to 18 Digits : In our previous Salesforce Training Tutorial we have learned about Social CRM. In this Salesforce Training Tutorial we are going to learn about what is the process of Converting 15 digit Salesforce opportunity ID to 18 Digits ID number.

Custom objects and Standard Objects in will have internal record ID. Internal record Id for all custom objects and Standard Objects like Opportunity, Account, Contact and so on will have only 15 digit ID number by default.

15 digit Id number will have numeric digits range from (0-9), a Lowercase letter(a-z) or a Uppercase letters(A-Z). 15 digit ID in is case sensitive. Example 100000000000ABC  is different from 100000000000abc. When using external productive tools like Microsoft Excel, MS Access and SQL Server external ID’s are not case sensitive and they don’t recognize the difference between 100000000000ABC  and 100000000000abc. has recognized this problem and has established 18 digit character insensitive ID. This 18 Digit ID is case insensitive which is formed by adding a suffix to the 15 Character Id number.

Ajay K DubediAjay K Dubedi
Internally, Salesforce uses a case-sensitive 15 digit ID for all records because everything is in control of salesforce but when doing callout in other words  
there are applications like Access or Excel which do not recognize that 50130000000014c is
 a different ID than 50130000000014C, the case-safe 18 character ID was introduced,
 18-character IDs can be safely compared for uniqueness by case-insensitive applications, and can be used in all API calls when creating, editing, or deleting data.

Amit & Ajay,
Thanks for your responses.

Both of you mentioned like its used in excel application. I have exported Account object records and got 18 digit ID. I have changed the 18 digit ID to Case insensitive form,

For example,

If original ID 001i000001AWbWuGTA menas, i changed to 001i000001AWbWugta.

If i try to update records using data loader/import wizard, then i am getting error malformed id/invalid.

Can any one explain the real time scenario. I am unable to understand to exact usage?
Amit Chaudhary 8Amit Chaudhary 8
ID fields in the user interface contain 15-character, base-62, case-sensitive strings. Each of the 15 characters can be a numeric digit (0-9), a lowercase letter (a-z), or an uppercase letter (A-Z). Two unique IDs may only be different by a change in case.

Because there are applications like Access which do not recognize that 50130000000014c is a different ID from 50130000000014C, an 18-digit, case-safe version of the ID is returned by all API calls. The 18 character IDs have been formed by adding a suffix to each ID in the API. 18-character IDs can be safely compared for uniqueness by case-insensitive applications, and can be used in all API calls when creating, editing, or deleting data.

If you need to convert the 18-character ID to a 15-character version, truncate the last three characters. recommends that you use the 18-character ID.

Please check below blog. How to covert 15 digit to 18 digit

Please let us know if this will help u

Amit, thanks for your quick response. I red defination in many site, I would like to know the real time scenario.

Thanks for your time..!
Hi All,

according to me if i give you an example.

00190000010mcww  & 00190000010mcwW (last 'W' in caps)  are same for some external system. but in salesforce it can be 2 different records.
so they appended 3 more character lets say 00190000010mcwwAAA & 00190000010mcwWAAA it is again same for external systems but Both ids wont be available in salesforce.

Arvind Yadav
Abdul trailheadAbdul trailhead

A 15 digit Salesforce ID is case sensitive. Ex:  00570000001ZwTi and 00570000001ZWTI are different.
A 18 digit Salesforce ID is case in-sensitive. Ex:  00570000001ZwTiXYZ and 00570000001ZWTIXYZ are same.
Even you can convert 15 digit Id to 18 digit by using code

Please find reference link below for code:

Mark if you convinced with this..

Suraj GharatSuraj Gharat

I think 18-char Ids are not excatly case-insensitives. There is one-to-one mapping between 15-char id to 18-char, that means for every 15-char id, there can be only one 18-char id, not more than one, thus we can not play with it by changing the case of its one or more characters.

18-char ids is just a workaround for the environments/platforms that dont recognize the the difference if the difference is only because of characters' case. There is a fixed formula to do this conversion and that formula ensures that two 15-char ids (Even with mere case difference), would generate twi different 18-char ids, such that the difference would not be because of case, rather it would be because of different characters. 

As we know that each record Id represents a unique record within an organisation. There are two versions of every record Id in salesforce :

15 digit case-sensitive version which is referenced in the UI
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.

Now how we can calculate the 18 Digit Id from 15 Digit Id :

//Our 15 Digit Id
String id = '00570000001ZwTi' ;

string suffix = '';
integer flags;

for (integer i = 0; i < 3; i++) {
          flags = 0;
          for (integer j = 0; j < 5; j++) {
               string c = id.substring(i * 5 + j,i * 5 + j + 1);
               //Only add to flags if c is an uppercase letter:
               if (c.toUpperCase().equals(c) && c >= 'A' && c <= 'Z') {
                    flags = flags + (1 << j);
          if (flags <= 25) {
               suffix = suffix + 'ABCDEFGHIJKLMNOPQRSTUVWXYZ'.substring(flags,flags+1);
               suffix = suffix + '012345'.substring(flags-25,flags-24);

//18 Digit Id with checksum
System.debug(' ::::::: ' + id + suffix) ;
Chris Wilson 58Chris Wilson 58
I needed to do this in Java so we can easily go between 15 and 18 digit IDs here is the logic ported to Java:
public String convertId2(String inputId) {
		String suffix = "";
		Integer flags;
		try {
			for (Integer i = 0; i < 3; i++) {
				flags = 0;
				for (Integer j = 0; j < 5; j++) {
					Character c = inputId.charAt(i * 5 + j);
					//int beginIdx = i * 5 + j;
					//int endIdx = i * 5 + j + 1;
					//System.out.println("" + inputId + "[" + beginIdx + ", " + endIdx + "] = \"" + c + "\"");
					if (Character.isUpperCase(c) && c >= 'A' && c <= 'Z') {
						flags = flags + (1 << j);
				if (flags <= 25) {
					suffix += "ABCDEFGHIJKLMNOPQRSTUVWXYZ".substring(flags, flags + 1);

				} else {
					suffix += "012345".substring(flags - 26, flags - 25);
				//System.out.println("Sufix: " + suffix);
		} catch (Exception exc) {
			throw new IllegalArgumentException("ERROR: Please enter Valid 15 digit Id");
		String outputId = inputId + suffix;
		return outputId;

And here is a sample test to make sure it works:
         String[] input = new String[] {

		for (String longId : input) {
            // Make a short id out of the long id
			String shortId = longId.substring(0, 15);
			String reconstitutedId = test.convertId2(shortId);
            // Check that long id 
			if (longId.equals(reconstitutedId)) {
			System.err.println("ERROR: " + longId + " != " + reconstitutedId);
			throw new RuntimeException("Values did not match!!!!");

Gug ChilGug Chil
WTF! come on guys! ANYBODY read the origin question!??? :))
What @SFDCLife says is true I have the same question!
If 18-character ID is case-insensitive, then WHY does salesforce acts like it would be a case-SENSITIVE! 
Just Query smthing like 
select id from Account where id = '0011t000008LR2nAAG'  
select id from Account where id = '0011T000008LR2nAAG'    // the letter 't' is uppercase now!
and we'll see that first query retrieves the id, and second query does NOT. So where is the logic lost !?
Edward PrignanoEdward Prignano
I'm lost!  We are using Jittbit to dataload some files.  One of the fields on the files is the Record ID, and the company providing the file switched to an all caps format so we started using the 18 character Record ID.  However, every time I try to use it, I get "insufficient access rights on cross-reference id..."  Is there ANY WAY to convert the 18 character to 15 character?  It worked fine using the 15 character Record ID. 
Chris Feldhacker IIChris Feldhacker II
To summarize:
  1. Both 15-character and 18-character Ids are CASE-SENSITIVE within Salesforce.  For a given Id, you cannot just change the case of characters within the Id and expect Salesforce to return the same results.  When interacting with Salesforce, you must preseve the case of Ids always.
  2. 15-character Ids must be compared in a case-sensitive manner.  Some common tools (such as Excel) are known to present challenges with this.
  3. 18-character Ids can be compared in a case-insensitive manner.  Performing comparisons with tools like Excel work "as expected".
  4. To convert an 18 character Id to a 15 character Id, just remove the last 3 characters of the Id.
  5. To convert a 15 character Id to an 18 character Id, then you need to use the special algorithm others have posted in order to compute the last 3 characters.  (The implication here is that if there is any change in case of any of the first 15 characters, then this would result in a change of one or more of the last 3 characters.)
The key takeaway is that Ids are always case-sensitive and case must be preserved when working within Salesforce.
The only time case-insensitive is a factor is when using various tools to compare Ids.  

For example, if you have a long list of 15-character Ids that you load into Excel, and you ask Excel to flag duplicates, then users often experience Excel incorrectly flagging two separate Ids as being duplicates.  This can happen when 2 different Ids have just 1 character present that differs by case -- Excel is comparing values in a case-insenstive way and considers two values that differ only by case to be the "same", but Ids with the same character but a different case are considered unique within Salesforce.  Determining two Ids to be a duplicate even though they are not can lead to lots of unexpected results.

In comparison, if you have a long list of 18-character Ids that you load into Excel, and you ask Excel to flag duplicates, then this works "as expected" and will not incorrectly flag two separate Ids as being duplicate.  This is because even though Excel is still performing a case-insensitive comparison of values, any two Ids that differ only by case in the first 15 character would have a different "checksum" computed.  Meaning, the last 3 characters for two Ids that differ only by case must be different.  Stated another way, you will not find two 18-character Ids in Salesforce that differ only by case.  Thus, Excel will never incorrectly identify two unique Salesforce Ids as being duplicates.

David Hansen 30David Hansen 30
Note: based on the (incredibly simple) algorithm used to calculate the extra 3-char case-sensitivity checksum (which is by no means a real checksum and can only be used for validity of the case of characters within the ID); you can absolutely reconstruct the proper case of the original ID from the additional 3-chars.   The following JavaScript code demonstrates how to do this:
function correct_SFID(id) {
  if (id.length != 18) {
    throw 'BAD SF ID - invalid length, must be 18 chars. current length = '+id.length;
  var corrected_id = '';
  var corrected_csum = '';
  for (var i = 0; i < 3; i++) {
    var csum_ch = id.charAt(15+i).toUpperCase();
    corrected_csum += csum_ch;
    flags = CSUM_IDX.indexOf(csum_ch)
    if (flags < 0) { throw 'BAD SF ID - invalid checksum character: "'+csum_ch+'"!'; }
    var rchunk = '';
    for (var j = 4; j >= 0; j--) {
      id_ch = id.charAt(i*5 + j)
      if (flags >= (1<<j)) {
        // According to checksum, this should be an uppercase char
        flags -= (1<<j);
        if ((id_ch >= 'a') && (id_ch <= 'z')) {
          rchunk += id_ch.toUpperCase();
        } else if ((id_ch >= 'A') && (id_ch <= 'Z')) {
          rchunk += id_ch;
        } else {
          throw 'BAD SF ID - invalid digit where alpha is expected: "' + id_ch + '"!';
      } else if ((id_ch >= 'A') && (id_ch <= 'Z')) {
        // According to checksum, this should be a lowercase char or digit
        rchunk += id_ch.toLowerCase();
      } else {
        // Unfortunately, we can't tell whether this char should be a
        // lowercase letter or a digit, but it's probably fine...
        rchunk += id_ch;
    // Add this chunk to the reconstructed ID in reverse order
    for (var j = rchunk.length; j >= 0; j--) { corrected_id += rchunk.charAt(j); }
  // Add the corrected case checksum
  corrected_id += corrected_csum;
  return corrected_id;

var id = process.argv[2];
console.log('Checking  SFID['+id+']');
console.log('Corrected SFID['+correct_SFID(id)+']');
Also, FWIW, I found no mention about doing this anywhere else... ??

And in example:
% node correct_sfid.js 0031i00000dzeh6qal
Checking  SFID[0031i00000dzeh6qal]
Corrected SFID[0031I00000DZeH6QAL]
HTH anyone else in the future...
Gaurav SadhwaniGaurav Sadhwani
@Chris Feldhacker II, thanks for explaning through, appreciated
Ad CadAd Cad

If you want to do ad-hoc conversions of Id's, rather than programatically, then this Chrome extension makes it easy:

FYI - I'm the developer. Please use the feedback form on the app if you'd like to suggest any improvements or additional functionality.