Canonical vs Isomeric SMILES: Why They're Not Opposites
Canonical SMILES vs isomeric SMILES aren't opposites; they're independent axes. When to use each, and why canonical is only canonical per toolkit.
“Canonical or isomeric?” gets asked as if it were one slider with two ends. It isn’t. Canonical and isomeric SMILES answer different questions, they’re independent of each other, and for most real work you want both at once. Treating canonical vs isomeric SMILES as a choice between two options is the misconception that produces duplicate database rows and silently dropped stereocenters. Here is what each term actually controls, why they’re orthogonal, and the vendor-terminology trap that makes the confusion worse.
Canonical: a unique string, by algorithm
A canonical SMILES is the one string a canonicalization algorithm picks out of the many valid SMILES for a molecule. Ethanol can be written CCO, OCC, or C(O)C — all correct, all the same molecule. Canonicalization runs a defined atom-ranking and traversal so that any of those inputs produces one agreed output. The point is reproducibility: feed the same molecule in tomorrow, get the same string, so you can use it as a dictionary key or a dedup signature. Canonical says nothing about stereochemistry on its own.
Isomeric: stereochemistry and isotopes included
An isomeric SMILES is one that carries stereochemistry and isotope information. Tetrahedral configuration is written with @ or @@; double-bond geometry uses / and \; isotopes go in brackets like [13C]. A non-isomeric SMILES omits all of that — it describes the constitution (which atoms bond to which) but not the 3D arrangement. Isomeric says nothing about uniqueness on its own.
Canonical vs isomeric SMILES: why they’re orthogonal, not opposite
Because one controls ordering and the other controls content, every combination exists:
| Non-isomeric | Isomeric | |
|---|---|---|
| Non-canonical | Any hand-written flat SMILES | Hand-written SMILES with @/@@ and /\ |
| Canonical | Toolkit’s unique string, stereo stripped | Toolkit’s unique string with stereo — usually what you want |
The lower-right cell — canonical and isomeric — is the default target for storing and comparing molecules: a reproducible string that still distinguishes (R) from (S). The two settings compose; they don’t trade off.
The trap: “canonical” is only canonical within one toolkit
There is no universal canonical SMILES. The canonical ordering is defined by a specific algorithm, so RDKit’s canonical string, OpenEye’s, and ChemAxon’s can all differ for the same molecule — and a toolkit can even change its algorithm between versions. A canonical SMILES is therefore a stable key within one tool and version, not across them. If you canonicalize in RDKit and a collaborator canonicalizes the same structure in a different toolkit, comparing the strings literally can report a false mismatch.
When you need identity that holds across tools and databases, that is exactly what InChI and the InChIKey are for — a single algorithm maintained by IUPAC, so the same molecule hashes to the same key everywhere. Our note on going from SMILES to InChI and InChIKey, and which to use when covers that handoff, and the broader trade-offs live in when to use which chemical identifier format.
The other trap: vendors disagree on what “isomeric” means
The word “isomeric” isn’t used identically across software. ChemAxon documents isomeric SMILES as a non-canonical string that includes stereo and isotopes; OpenEye documents its isomeric SMILES as a canonical string that includes them. Same word, different default for the canonical axis. Before you rely on a function’s name, read what it actually returns — whether it canonicalizes, whether it includes stereo, or both. The label is not a reliable guide on its own.
Which to generate, by task
Deduplicating or keying a compound set within one pipeline: canonical, and isomeric too if your set contains stereoisomers you need to keep distinct. Pick one toolkit and version and stay on it.
Communicating a specific stereoisomer to a colleague or a script: isomeric, so the configuration travels. Canonical is optional here — a hand-written isomeric string is fine for one molecule.
Matching against an external database or another group’s tooling: don’t trust canonical SMILES across the boundary. Generate a canonical isomeric SMILES for your own records, but use the InChIKey as the cross-tool match key.
Quick visual or constitutional check where stereo is irrelevant: non-isomeric is fine and shorter.
Seeing the difference on a real structure
Paste a stereo-bearing molecule — say (S)-ibuprofen — into our SMILES-to-structure tool and the copy cluster gives you a button labeled Canonical SMILES (RDKit) right next to plain SMILES, InChI, and InChIKey. The label names the method on purpose: it is canonical for RDKit, and the string recomputes from the live structure as you edit, so you can watch a stereocenter appear or disappear in the isomeric output. That makes the orthogonality concrete instead of abstract.
Hold the two ideas separately and the confusion clears: canonical answers “is this the one agreed string?”, isomeric answers “does it carry the stereochemistry?”, and the cross-tool identity question belongs to the InChIKey, not to either SMILES flag. The OpenSMILES specification and the SMILES specification overview document both axes precisely.