MOL File to SMILES: What Survives the Conversion and What Doesn't
Convert a MOL file to SMILES cleanly: what survives, what drops (coordinates, SDF fields, stereo), and how to verify the round-trip in RDKit.
A collaborator sends an SDF, a database export hands you a folder of MOL files, and you need a column of SMILES for a spreadsheet or a quick RDKit script. The conversion itself takes one function call. The part that bites later is what quietly drops on the way: the moment you convert a MOL file to SMILES, you trade a coordinate-bearing graph for a connectivity string, and a few things in the MOL block do not make the trip. Here is how to do the conversion cleanly and, more usefully, exactly what survives and what does not.
What a MOL file holds that SMILES does not
A MOL/SDF block (the MDL CTfile format) stores an atom block with x/y/z coordinates, a bond block with orders and stereo flags, optional property lines, and — in an SDF — tagged data fields after the structure. SMILES stores the molecular graph: atoms, bonds, charges, stereo, isotopes. The graph is the part both formats share. Everything the MOL carries around the graph is where loss happens.
Step 1 — Check what your MOL actually carries
Open the file and look at two things before converting. First, the version stamp on the counts line: V2000 or V3000. Second, whether the coordinates are real 2D/3D positions or all zeros (some database dumps ship flat, coordinate-free blocks). If your downstream use needs geometry — docking, a 3D overlay, a figure laid out a specific way — stop here, because SMILES will not preserve it. If you only need identity and connectivity, continue.
Step 2 — Convert the MOL file to SMILES
Any cheminformatics toolkit reads the block and writes the string. In RDKit that is Chem.MolFromMolFile(path) then Chem.MolToSmiles(mol); the second call returns canonical SMILES by default. If you want the stereochemistry carried through, keep isomericSmiles=True (RDKit’s default) — turning it off strips the @/@@ and /\ markers even when the MOL defined them. For a one-off or a visual check, paste the block into a structure editor and read the SMILES back out, which also lets you confirm the toolkit perceived the molecule the way you expect.
Step 3 — Verify the round-trip on stereocenters
The conversion step most worth checking is stereochemistry. A V2000 MOL encodes tetrahedral configuration through 2D wedge/hash bonds plus the atom-parity column; the toolkit reads those and assigns @/@@. If the source block used wedges inconsistently, or left a stereocenter undefined, the SMILES will faithfully record “undefined” — which is correct, but easy to miss. Generate the structure back from your new SMILES and confirm the stereocenters match the original drawing. Getting R/S wrong is the one error a chemist notices instantly.
What survives and what is dropped
| MOL/SDF content | In the SMILES? |
|---|---|
| Atoms, elements, bond orders | Preserved |
| Formal charges | Preserved |
| Isotope labels | Preserved |
| Defined stereo (wedge/parity → @/@@, cis/trans) | Preserved if isomeric SMILES is requested |
| 2D layout coordinates | Dropped — SMILES is a graph, not a drawing |
| 3D conformer coordinates | Dropped |
| SDF tagged data fields (IDs, assay values, properties) | Dropped — they belong to the SDF record, not the molecule |
| Atom-atom maps (reaction context) | Dropped in plain SMILES |
| S-groups, polymer brackets, R-group/query features | Dropped or degraded |
| Explicit vs implicit hydrogens | Normalized — most become implicit |
The aromaticity caveat
A MOL block represents rings in Kekulé form — explicit single and double bonds. When the toolkit writes SMILES, it re-perceives aromaticity and may output lowercase aromatic atoms (c1ccccc1 for benzene). The molecule is unchanged; the depiction of the bonds in the string is the toolkit’s model, not the MOL’s. This matters when you compare SMILES strings literally, because two toolkits can perceive aromaticity differently and produce different-looking strings for the same molecule. If you need a string you can compare across tools, generate a canonical InChI or InChIKey alongside — our note on going from SMILES to InChI and InChIKey, and which identifier to use when covers that choice.
When SMILES is the wrong target
Convert to SMILES when you need identity, connectivity, dedup keys, or a compact string for scripting and inline communication. Keep the MOL or SDF when you need coordinates, reaction atom-mapping, query/R-group features, or the data fields attached to each record. For the difference between SMILES and the canonical cross-database identifiers, see when to use which chemical identifier format.
To do the conversion without writing a script — or just to sanity-check one structure — paste the MOL or SDF block into our SMILES-to-structure tool: it auto-detects the format, lays out the molecule, and gives you canonical SMILES, InChI, and InChIKey from the live structure, with a warning when an export would drop information the molecule carries. The connectivity comes across every time; spend your verification effort on the stereocenters, where the cost of a silent error is highest. The RDKit documentation and the Daylight SMILES theory manual document the conversion behavior in full.