SeqChem

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.