If you have ever tried to match compounds across two databases and found that the same molecule
appears twice, the culprit is usually the representation format. SMILES, InChI and InChIKey all
describe a structure, but they differ in what they guarantee — and only one of them is safe as a
primary key.
SMILES: compact, human-writable, not canonical
SMILES (Simplified Molecular Input Line Entry System) writes a molecule as a traversal of its
graph. Atoms are element symbols, bonds are implicit or written as -, =,
#, branches use parentheses and rings use digit closures.
Aspirin, for example, can be written as:
CC(=O)Oc1ccccc1C(=O)O OC(=O)c1ccccc1OC(C)=O O=C(O)c1ccccc1OC(=O)C All three are valid and describe the same molecule. That flexibility is exactly the problem: a
string comparison of two SMILES is not a comparison of two molecules.
What SMILES is good for
- Pasting into a structure editor or drawing tool
- Compact storage inside a script or a database column you control
- SMARTS substructure queries (SMARTS is SMILES extended with wildcards)
- Input to almost every cheminformatics toolkit
What SMILES is bad for
- Deduplication — unless you canonicalise first
- Cross-database lookup — different toolkits canonicalise differently
- Regulatory or archival identifiers
Most toolkits do have a canonical SMILES algorithm, but "canonical" is toolkit-specific. RDKit's
canonical SMILES and OpenBabel's canonical SMILES are both deterministic and both perfectly
valid — and they are not guaranteed to produce the same string. That makes canonical SMILES a
good internal key and a poor external one.
InChI: canonical by standard
InChI (International Chemical Identifier) is maintained by IUPAC and designed specifically to be
a canonical, non-proprietary identifier. Every conforming implementation must produce the same
string for the same structure. The format is layered:
InChI=1S/C9H8O4/c1-6(10)13-8-5-3-2-4-7(8)9(11)12/h2-5H,1H3,(H,11,12) -
1S— version 1, standard InChI -
C9H8O4— molecular formula layer -
c1-6(10)13-...— connectivity layer -
h2-5H,1H3,(H,11,12)— hydrogen layer
Separate layers also cover charge, stereochemistry (including /t and /m
sub-layers) and isotopes. If a structure has no stereo, those layers are simply absent.
Why InChI exists
Before InChI, every vendor had its own canonical form. InChI gave the community a single
reference string that could be published in a paper or deposited with a patent and re-derived
later by anyone. PubChem, ChEMBL, Wikidata and most patent databases index by InChI and
InChIKey.
The downside: length
A full InChI is long, contains punctuation that needs escaping in URLs, and grows with molecule
complexity. For a small molecule it is ~60 characters; for a peptide or a natural product it can
be hundreds. Indexing millions of them is possible but not free.
InChIKey: fixed-width hash
The InChIKey is a hash of the InChI, always exactly 27 characters:
BSYNRYMUTXBXSQ-UHFFFAOYSA-N The three blocks are meaningful:
- First 14 — the molecular skeleton (connectivity plus formula)
- Next 8 — stereochemistry, charge and isotope layers
- Final 1 — a check character to catch transcription errors
Because the first block ignores stereo, two enantiomers share the same 14-character prefix and
differ only in the second block. That is convenient for "find me anything with this skeleton"
queries.
What InChIKey cannot do
It is a one-way hash. You cannot recover a structure from a key, and you cannot convert a key
into anything else. Keep the InChI or the original structure file alongside it. Also note that
the key is case-sensitive — BSYNRYMUTXBXSQ-UHFFFAOYSA-N and its lowercase form are
different strings to a database.
Which one should you use?
| Task | Use |
|---|---|
| Pasting into a drawing tool | SMILES |
| Deduplicating a library | InChI (or InChIKey) |
| Primary key in a database | InChIKey, with InChI stored alongside |
| Matching against PubChem / ChEMBL | InChIKey |
| SMARTS substructure search | SMILES / SMARTS |
| Filing a patent or a regulatory dossier | InChI |
Converting between them
All three conversions are one click on this site: SMILES to InChI,
InChI to SMILES, SMILES to
InChIKey and InChI to InChIKey. Two rules of thumb:
- Always convert toward InChI when you cross a system boundary, never away from it.
- Never rely on a SMILES string being stable across tools; canonicalise at the point of entry.
SeqChem has free browser tools for all of this: SMILES to InChI, InChI to SMILES and SMILES to InChIKey.

