Decoding VIN Positions 4–8: What the Vehicle Descriptor Section Tells You via NHTSA vPIC

The first three characters of a VIN tell you who built the vehicle. Positions 10–17 tell you when and where it was finished, plus its serial number. The quiet middle — positions 4 through 8, the Vehicle Descriptor Section (VDS) without the check digit — is where most of the "what is this car?" information lives.

If you call NHTSA's free vPIC API (DecodeVinValues or DecodeVin), those five characters drive a surprising number of the fields you get back: body style, restraint system, drive type, engine family, and more. This post is a practical map of what that section means, what the API actually returns, and where teams usually over-interpret the data.

Where the VDS sits in a 17-character VIN

Under ISO 3779 / 49 CFR 565, a modern North American VIN looks like this:

Positions	Name	Job
1–3	WMI	World Manufacturer Identifier
4–8	VDS (descriptor)	Model / series / body / restraint / engine encoding
9	Check digit	ISO 3779 / CFR check
10	Model year	Encoded year code
11	Plant	Manufacturer plant code
12–17	Serial	Production sequence (small makers: 12–14 continue identity)

Position 9 is often taught as part of the "VDS" in textbooks, but for decoding work it is cleaner to treat 4–8 as the descriptor and 9 as its own validation character. The check digit is computed from the other 16 characters; it does not describe the vehicle.

Manufacturers assign the meaning of positions 4–8. There is no universal "position 5 always means doors." Honda's encoding is not Toyota's. That is why you do not hand-parse the VDS with a static lookup table — you ask the manufacturer tables that NHTSA has on file.

What NHTSA vPIC returns from those five characters

vPIC endpoints live under https://vpic.nhtsa.dot.gov/api/vehicles/ and need no API key. For a full VIN, the workhorse is:

GET /api/vehicles/DecodeVinValues/{VIN}?format=json

The JSON Results[0] object is a flat bag of named fields. Many of the interesting ones are resolved from the VDS (plus WMI context), including fields such as:

• Make, Model, ModelYear (year also uses position 10)
• BodyClass, Doors, Series, Trim (when available)
• DriveType, EngineCylinders, DisplacementL, FuelTypePrimary
• SeatBeltsAll, OtherRestraintSystemInfo, airbag-related fields
• VehicleType, PlantCity / PlantCountry (plant leans on position 11)
• ErrorCode, ErrorText, AdditionalErrorText

Not every field is populated for every VIN. Empty strings are normal. Treat blanks as "unknown to vPIC," not as "this car has no airbags."

A compact TypeScript shape for the fields you will actually use:

type VpicDecode = {
  VIN: string;
  Make: string;
  Model: string;
  ModelYear: string;
  BodyClass: string;
  Doors: string;
  DriveType: string;
  EngineCylinders: string;
  DisplacementL: string;
  FuelTypePrimary: string;
  Series: string;
  Trim: string;
  VehicleType: string;
  ErrorCode: string;
  ErrorText: string;
};

const BASE = "https://vpic.nhtsa.dot.gov/api/vehicles";

export async function decodeVin(vin: string): Promise<VpicDecode> {
  const url = `${BASE}/DecodeVinValues/${encodeURIComponent(vin)}?format=json`;
  const res = await fetch(url);
  if (!res.ok) throw new Error(`vPIC HTTP ${res.status}`);
  const data = await res.json();
  return data.Results[0] as VpicDecode;
}

Always read ErrorCode / ErrorText. A successful HTTP 200 can still mean a partial decode (wrong check digit, incomplete manufacturer data, or a VIN pattern NHTSA only partly recognizes).

What the VDS is good for in product code

Marketplace listing validation. Compare the seller's typed make/model/body against the decode. If the ad says "Crew Cab 4x4 diesel" and vPIC returns a 2-door gasoline passenger car, stop and ask for clarification before money moves.

Inventory normalization. Dealers and importers paste free-text descriptions. Mapping BodyClass, DriveType, and engine fields from the VIN gives you consistent filters without trusting the ad copy.

Recall and campaign prep. Recall APIs usually want make/model/year. Decoding first turns a VIN into those keys. (Use VIN-specific recall lookups when you need "open on this exact vehicle," not just model-level campaigns.)

Buyer education UIs. Showing "what the VIN claims this vehicle is" next to the listing photo is useful even when you are not selling a full history report.

What the VDS / free decode is not

A VDS-backed decode answers identity: what the manufacturer registered this VIN pattern as. It does not answer:

• Whether the car was totaled, flood-damaged, or branded salvage
• Odometer history or title brands (those come from DMV / NMVTIS-style systems, not vPIC)
• Theft status (use law-enforcement / NICB-style tools for that)
• Whether the physical car matches the metal (cloning, restamped plates, swapped dash clusters)

If your product copy blurs "decode" and "history report," you will train users to trust the wrong layer of data.

Manufacturer-specific encoding (and why scrapers fail)

Because positions 4–8 are manufacturer-defined, community "VDS charts" go stale the week a new powertrain ships. NHTSA's tables are updated when manufacturers file; your job is to call the API, not to maintain a private Honda spreadsheet.

Practical habits:

1. Validate length, charset (no I/O/Q), and check digit before calling vPIC.
2. Decode with DecodeVinValues and keep the raw field map for audit logs.
3. Cache by VIN — a VIN's manufacturer decode does not change over time.
4. Surface empties honestly in the UI ("Trim not reported") instead of inventing defaults.
5. Re-check ErrorText when Make/Model come back blank even though the VIN looks fine.

For partial VINs or research tools, vPIC also exposes pattern and flat decode variants; start with a full 17-character VIN in production flows.

A buyer-facing checklist you can ship

When you expose VDS-derived fields to non-technical users, keep the language concrete:

1. Make and model match the listing title.
2. Body class and door count match the photos.
3. Drive type and fuel type match what the seller claims.
4. Model year from the VIN matches the year in the ad (remember: model year ≠ calendar build date).
5. Any blank critical field is called out, not hidden.

That checklist is enough for an MVP "VIN vs listing" panel without pretending you have title history.

Wrapping up

Positions 4–8 are the manufacturer's compressed description of the vehicle. NHTSA vPIC expands them into structured fields you can validate, filter, and display — as long as you respect empty values, error codes, and the hard line between identity decode and history / title / theft data.

Disclosure: I maintain VIN Lookup, a free VIN decoder that builds on public NHTSA vPIC data. Not affiliated with NHTSA.