Get an InChIKey from a SMILES - and Use It to Search a Database

You have a SMILES and a question: is this compound already in PubChem, in our registration database, in the assay results from last quarter? You can’t reliably search a database with a SMILES — different tools write different “canonical” SMILES for the same molecule, so a string match misses real hits. The fixed key for that job is the InChIKey. To get an InChIKey from a SMILES, you convert the structure to a standard InChI and hash it; the result is a 27-character string that’s the same everywhere, built for search and deduplication. This shows how to generate it, how to search with the full key versus just the connectivity block, and the normalization behavior that surprises people.

Why the InChIKey, not the SMILES

A SMILES is portable and editable, but its canonical form is toolkit-specific — RDKit, OpenEye, and ChemDraw can each emit a different canonical SMILES for the same molecule, so none of them is a dependable database key. The standard InChI is the opposite: one molecule yields exactly one standard InChI regardless of software, and the InChIKey is its fixed-length hashed digest. That’s what makes it searchable and dedup-safe. For the broader question of which identifier to use when — SMILES versus InChI versus InChIKey — the companion post lays out the trade-offs; this one is about generating the key and putting it to work.

From SMILES to InChIKey

1. Load the SMILES as a structure (paste it; the parser perceives the molecule).
2. Generate the standard InChI — the tool runs the IUPAC InChI algorithm to produce the canonical layered string.
3. Hash to the InChIKey — copy the 27-character result.

The structure of the key tells you how to search with it. An InChIKey looks like BSYNRYMUTXBXSQ-UHFFFAOYSA-N (aspirin) and has three parts: a 14-character connectivity block (the molecular skeleton), a 10-character block that is an 8-character hash of the stereochemistry, isotope, and charge layers plus two flag characters (a standard-InChI indicator and a version flag), and a final flag character for protonation. Two stereoisomers share the first block but differ in the second.

Search a database with it

Paste the InChIKey straight into PubChem or ChemSpider. A full-key hit confirms the exact compound, stereochemistry included. A first-block hit (search the 14 characters) returns the connectivity family — useful when you suspect the database has your compound but with different or missing stereo. For an internal registration or ELN database, store the InChIKey as an indexed column and you get the same dedup behavior: a new structure’s key either matches an existing row or it doesn’t, no fuzzy string comparison required.

What trips people up

• Standard InChI normalizes tautomers. The keto and enol forms of a compound collapse to the same standard InChIKey. That’s a feature for dedup — the database treats them as one compound — but a surprise if you pasted one tautomer and expected a key unique to that exact form.
• A first-block match means “same skeleton,” not “proven identical.” Hash collisions across different molecules are vanishingly unlikely, but the right discipline is to treat a connectivity-block match as a strong candidate and confirm with the full key plus the actual structure.
• Salts and multi-component inputs get their own key. The InChIKey of a hydrochloride salt differs from the parent’s. Decide whether you’re searching for the parent compound or the specific salt form, and generate the key from the matching structure — strip or keep the counterion deliberately, not by accident.

Generate and copy the key

The SMILES to structure tool parses a SMILES (or InChI or MOL) onto an editable canvas and copies the standard InChI or the InChIKey in one click — so you can confirm the structure by eye before you trust the key you’re about to search. For how the identifiers relate, see InChI versus SMILES and getting an editable structure from a string. The InChI standard itself is maintained by the InChI Trust.