Squish and nano build codes

A nano is a build code cut from a VIN: positions 1 to 8, a * in place of the check digit, then positions 10 and 11, plus positions 12 to 14 when position 3 is 9. A squish is shorter: positions 1 to 8 plus position 10. Every VIN from the same build shares one nano, and every VIN of the same configuration and model year shares one squish, whatever plant built it. Both come from the VIN alone, so you can compute them offline, and Cardog uses them as join keys across specs, listings and market prices.

Written by Cardog. Where we describe a public authority's rules, or another company's use of a term, we link its own page, checked on 2026-10-26.

Why a build code

A VIN identifies one vehicle. Most questions are about a group of vehicles: what this configuration's spec sheet says, what cars like this one are listed for, which recalls name this model year. For those questions you want a key that every vehicle in the group shares and that leaves out what makes each one unique.

1234

1. 1Bodyrefs.bodyStyle
2. 2Enginerefs.fuelType; the full sheet at links.specs
3. 3Transmissionrefs.transmission, null when not derivable
4. 4Driverefs.driveType

The VIN already has that structure (49 CFR 565.15; Motor Vehicle Safety Regulations, s. 115(3)):

Drop the check digit and the serial and what remains describes the build. That is the idea behind both keys.

Squish: one configuration of one model year

A squish keeps positions 1 to 8 and position 10. It is nine characters.

It leaves out the plant on purpose. Two vehicles of the same configuration and model year share a squish even if they came from different plants, which makes it the level Cardog uses to group listings for market prices.

Nano: one build

A nano keeps positions 1 to 8, puts * where the check digit was, then keeps positions 10 and 11. It is eleven characters.

The plant is in the key because vehicles with the same descriptor can differ by plant. When position 3 is 9, the manufacturer builds fewer than 1,000 vehicles of that type a year and its identifier is completed by positions 12 to 14 (49 CFR 565.15(a) and (d)(3); MVSR, s. 115(3)(a.1)). For those VINs the nano keeps positions 12 to 14 and is fourteen characters, so that two small manufacturers sharing a three-character code are never folded into one. For every other VIN, positions 12 to 14 are serial and stay out.

The ref form drops the *

The * is always in the same place, so when Cardog writes a nano as a ref it leaves the star out: 2T3R1RFV*MW becomes nano:2T3R1RFVMW, a 10-character key (13 for a small manufacturer). Parsing the ref puts the star back. A squish ref is squish: plus its nine characters. Both are uppercase.

Worked examples

Reading the first row: positions 1 to 8 are 2T3R1RFV, position 9 is the check digit 7 (masked), position 10 is M (2021), position 11 is W (the plant), and 180266 is the serial. The last row is a small manufacturer's VIN, so 132 from positions 12 to 14 stays in the nano. The rows marked test VIN come from Cardog's own test suite and carry made-up serials.

How this compares to "squish VIN" elsewhere

Other companies use "squish VIN" for a ten-character key: positions 1 to 8 plus 10 and 11. Auto.dev defines a Squish VIN as a 10-character version of the VIN made of positions 1 to 8 and 10 to 11, without the check digit and the serial number (Auto.dev). Edmunds' developer documentation describes a squish VIN as "basically the first 11 digits of the VIN minus the 9th digit which is a check digit" (Edmunds).

So the names cross over:

For most VINs, the "squish VIN" others use has the same characters as Cardog's nano ref key: for 2T3R1RFV7MW180266 both are 2T3R1RFVMW. Cardog's squish is one character shorter because it leaves out the plant. If you are matching keys between systems, compare positions, not names.

In the API

• GET /v2/vin/{vin} returns nano (for example nano:2T3R1RFVMW) and squish (for example squish:2T3R1RFVM) for every VIN that decodes. Both are null when valid is false, so a VIN that does not decode never joins to a group.
• GET /v2/specs/nano:{code} returns the spec sheet for one build. When a VIN's build has its own entity, the decode's links include specsBuild, safetyBuild and partsBuild pointing at the build's routes, and nanoEntity for the build itself.
• GET /v2/quotes/squish:{key} prices one configuration of one model year from live listings, and GET /v2/quotes/model-year:{...} prices the whole model year. See Market data.
• Listing search takes a nanos filter, so you can pull every live listing of one build.
• Offline, the @cardog/entities package has squishFromVin, nanoFromVin, squishRef, nanoRef and nanoFromRef, so you can key your own tables before you call the API. See Ref grammar.

import { squishFromVin, nanoFromVin, nanoRef, squishRef } from "@cardog/entities";

squishFromVin("2T3R1RFV7MW180266");         // "2T3R1RFVM"
nanoFromVin("2T3R1RFV7MW180266");           // "2T3R1RFV*MW"
nanoRef(nanoFromVin("2T3R1RFV7MW180266"));  // "nano:2T3R1RFVMW"
squishRef("2T3R1RFVM");                     // "squish:2T3R1RFVM"
nanoFromVin("1S9TS101891132038");           // "1S9TS101*91132"

FAQ

Why mask the check digit instead of keeping it? Because it changes from vehicle to vehicle. It is computed from all sixteen other characters, including the serial, so two cars from the same build usually have different check digits. Keeping it would split one build into many keys.

Why does the nano keep the plant but the squish does not? They answer different questions. A nano names one build, and the plant can matter for that. A squish groups a configuration across plants, which gives a market price more listings to work from.

What is the difference between nano and the "squish VIN" other APIs use? For a standard VIN, none in content: both are positions 1 to 8, 10 and 11. Cardog's nano also keeps positions 12 to 14 when position 3 is 9, and its ref form is prefixed nano:.

Can I compute these without calling the API? Yes. They are pure functions of the VIN. Use @cardog/entities or the position rules on this page.

Why is a nano sometimes 14 characters? When position 3 of the VIN is 9, positions 12 to 14 are part of the manufacturer's identifier, so they stay in the key. The ref form is then 13 characters.

Related

• What a VIN tells you
• How used-car prices are measured
• VIN structure (docs)
• Decode a Canadian VIN (docs)
• Ref grammar (docs)
• Market data (docs)

Sources

Checked on 2026-10-26:

• 49 CFR Part 565, Vehicle Identification Number Requirements (eCFR): https://www.ecfr.gov/current/title-49/subtitle-B/chapter-V/part-565
• Motor Vehicle Safety Regulations, C.R.C., c. 1038, section 115 (Justice Laws): https://laws-lois.justice.gc.ca/eng/regulations/C.R.C.,_c._1038/FullText.html
• Auto.dev, What is a Squish VIN?: https://www.auto.dev/blog/what-is-a-squish-vin
• Edmunds developer documentation, Squish VIN: https://developer.edmunds.com/api-documentation/vehicle/spec_squishvin/v2/

If something here is wrong, tell us and we will fix it.