InChIKey

The InChIKey, sometimes called the hashed InChI, is a fixed-length, 27-character text identifier derived from a full IUPAC International Chemical Identifier (see InChI). It was introduced by the InChI project, which is developed by IUPAC together with NIST and maintained today by the InChI Trust, to give each chemical structure a compact, uniform label suitable for web search engines, spreadsheets, and database indexing—use cases where a variable-length InChI string is awkward. Unlike the InChI it summarizes, an InChIKey has a predictable size and consists only of uppercase Latin letters and two hyphens, so search engines treat it as a single token.

Structurally an InChIKey looks like AAAAAAAAAAAAAA-BBBBBBBBFV-P. The first block of 14 letters is a truncated SHA-256 hash of the InChI connectivity (skeletal) layers; the second block of 8 letters hashes the remaining layers such as stereochemistry, isotopic substitution, and tautomer/proton information. Appended to the second block are two flag characters: a standard flag (S for a standard InChIKey, N for non-standard) and a version letter (A for InChI version 1). A final single letter after the last hyphen encodes the net protonation state (N for neutral, and other letters for charged states). Because the hash blocks are seeded from an actual InChI, two structures that share a skeleton but differ only in stereo or isotopes share the first block while differing in the second—a useful property for coarse-to-fine matching.

The defining trade-off is that InChIKey is a one-way hash: the original structure cannot be reconstructed from the key. It is therefore not a structure-encoding format like InChI, SMILES, Molfile, or CML, but a lookup surrogate that must be resolved against a registry (for example PubChem or a resolver service) to recover chemistry. Generation is typically done with the official InChI software or cheminformatics toolkits such as RDKit and Open Babel, which emit the standard InChIKey alongside the InChI.

Because it relies on hashing, InChIKey is not strictly collision-free; collisions are mathematically inevitable but were engineered to be vanishingly rare across databases of tens of millions of compounds. Its strengths are compactness, constant length, and near-uniqueness for practical indexing and cross-referencing; its limitations are irreversibility, dependence on a resolver, and the theoretical (if negligible) collision risk that make it unsuitable as a sole record of structure.