Working with NHTSA FARS Data: What the Documentation Doesn't Tell You

We built farsapi.com by ingesting every FARS CSV from 2017 through 2023. This is what we learned - the schema changes, encoding traps, and silent data gaps that will break your pipeline if you don't know about them.

NHTSA's FARS Analytical User's Manual is 400+ pages. It documents the intended schema. What it doesn't document well is how the schema actually behaves when you try to load seven years of data into a database and query across them. This guide covers the gaps.

The ACCIDENT table lost columns you probably expect

If you've worked with older FARS data (pre-2020), you might expect to find DRUNK_DR, SP_LIMIT, SUR_COND, and HIT_RUN on the ACCIDENT table. They're gone.

Starting with the 2020 data year, NHTSA removed several crash-level summary fields from the ACCIDENT CSV. The data still exists - it just moved to the VEHICLE table or needs to be computed:

FieldPre-20202020+What to do
DRUNK_DR On ACCIDENT table Removed Count vehicles where DR_DRINK=1 on VEHICLE table
HIT_RUN On ACCIDENT table Removed Check HIT_RUN on VEHICLE table - if any vehicle is flagged, the crash is hit-and-run
SP_LIMIT On ACCIDENT table Removed Use VSPD_LIM on VEHICLE table (per-vehicle, not per-crash)
SUR_COND On ACCIDENT table Removed entirely No direct replacement. Road surface condition is no longer recorded at the crash level in these years.

This isn't documented as a breaking change anywhere obvious. The User's Manual for 2023 simply doesn't list these fields. If you're writing an ingest pipeline that spans pre-2020 and post-2020 data, you need conditional logic - and you need to decide whether to derive crash-level values from vehicle-level data or leave them null for the newer years.

FARS API computes drunk_drivers and hit_and_run at the crash level by aggregating from vehicle records. Speed limit is returned per-vehicle only, because that's where the data actually lives.

BAC is stored as an integer, not a decimal

The ALC_RES field on the PERSON table looks like it should be a Blood Alcohol Concentration - and it is - but it's encoded as an integer where 148 means 0.148 BAC. The legal limit in most US states is 0.08 BAC, which is stored as 80.

If you load this column as-is into your database, you'll get BAC values of 148, 217, 53 - which look like nonsense unless you know to divide by 1000.

There's a second trap: values 995–999 are special codes, not BAC readings:

ALC_RES valueMeaning
0BAC = 0.000 (tested, no alcohol)
1–940BAC = value / 1000 (e.g., 148 = 0.148)
995Test Not Given
996Test Refused
997Test Performed, Results Unknown
998Not Reported
999Unknown

In our dataset, 79,334 persons tested at 0.000 BAC. 8,334 tested between 0.001 and 0.080 (under legal limit). 32,526 tested above 0.080. And 444 tested above 0.400 - which sounds impossible, but these are fatal crash records. Those people are almost always dead.

FARS API returns BAC as a proper decimal (0.148, not 148) and strips the special codes to null.

Vehicle model names require VPIC, not the MODEL column

The VEHICLE table has a column called MODEL. You'd reasonably assume it contains model names. It doesn't - it contains NHTSA's internal numeric model codes (e.g., 12481 for a Ford F-250, 20421 for a Chevrolet Tahoe).

The human-readable model name is in VPICMODELNAME - a column that comes from NHTSA's Vehicle Product Information Catalog (vPIC) decoder. Similarly, MAKENAME has the make name, and VPICBODYCLASSNAME has a detailed body type description.

Not every vehicle has a VPIC decode. About 3.4% of vehicle records have only numeric codes for the model - typically older vehicles, custom builds, or cases where the vehicle couldn't be identified precisely. Those records fall through to the raw MODEL code.

This matters if you're building queries like "find all crashes involving Toyota Camry." Searching the MODEL column returns nothing useful. You need VPICMODELNAME.

Body type labels are more specific than you'd expect

The BODY_TYP column uses numeric codes (14 = SUV, 30 = Pickup, etc.), and NHTSA's BODY_TYPNAME column provides the official labels. But these labels are verbose:

If you use the raw NHTSA labels, your API responses will have 90-character body type strings. If you write your own labels from the coding manual, you'll have shorter strings - but you'll need to maintain them across years as NHTSA occasionally changes code definitions.

FARS API uses NHTSA's own labels from the CSV (BODY_TYPNAME) for accuracy, even though they're verbose. When querying by body type, partial matching handles the verbosity - searching "Pickup" matches "Light Pickup" and "Light Pickup Truck."

Column names change between years (quietly)

We diffed every CSV header across 2017–2023. Most columns are stable, but there are changes that will break a naive ingest pipeline:

TableYearsChange
ACCIDENT2022 → 2023BOM encoding changed (UTF-8 BOM on STATE column in 2022, clean in 2023)
VEHICLE2020 → 2021UNDERIDE renamed to UNDEROVERRIDE
VEHICLE2022 → 2023ACC_CONFIG and ACC_CONFIGNAME added
PERSON2021 → 2022ALC_DET and DRUG_DET removed; DEVMOTOR and DEVTYPE added

The BOM issue is particularly insidious. In 2022, the first column reads as STATE instead of STATE. Standard CSV parsers handle this silently in some languages (Python's utf-8-sig codec) and fail silently in others - your code runs, but the first column doesn't match by name.

The column renames aren't announced in a changelog. You discover them when your pipeline throws a KeyError on a column that existed last year.

GPS coordinates: good but not perfect

99.6% of crashes in 2017–2023 have GPS coordinates. That's excellent. But there are caveats:

FARS API filters sentinel values and serves null for coordinates that aren't real. Radius queries automatically exclude crashes with missing coordinates.

FATALS is the only field that's truly reliable across all years

Every crash in FARS has at least one fatality - that's the inclusion criterion. The FATALS field on the ACCIDENT table is always present, always >= 1, and consistently defined. It's the one field you can count on never being null, never being a special code, and never changing meaning between years.

Our dataset: minimum 1, maximum 13, average 1.09. That average tells you most fatal crashes have exactly one fatality - which matters for actuarial models that might otherwise assume higher counts.

The same category has different label wordings in different years

NHTSA's MAN_COLLNAME column (manner of collision) uses different wordings for the SAME category across years. For the single-vehicle / not-a-collision-with-another-motor-vehicle category, we observed at least three distinct labels in the source CSVs:

If you GROUP BY manner_of_collision across multi-year data, you'll get three buckets that should be one. This silently corrupts any "most common collision type" analysis. NHTSA documents the code (0 = "Not a Collision with Motor Vehicle in Transport") as stable, but the human-readable label drifts.

The fix: normalize at query time. Match on the code (MAN_COLL = 0), or canonicalize labels containing "Not a Collision with" + "Motor Vehicle" into one bucket. The same trap exists for some weather and light condition labels - watch for slash vs comma drift ("Fog/Smog/Smoke" vs "Fog, Smog, Smoke").

The hardcoded code-to-label tables in the user manual are wrong

NHTSA's FARS Analytical User's Manual (DOT HS 813 556, 2023 edition) lists code-to-label mappings for every variable. We built our initial code lookup tables from those tables. They contained errors.

Specifically, the REST_USE (restraint use) codes 1, 2, 3, and 4 in the manual we worked from were transposed:

CodeWhat we had (wrong)What NHTSA's REST_USENAME column actually says
1None UsedShoulder Belt Only Used
2Shoulder Belt OnlyLap Belt Only Used
3Lap Belt OnlyShoulder and Lap Belt Used
4Shoulder and Lap BeltChild Restraint Type Unknown

This is the difference between "the deceased was not wearing a seat belt" and "the deceased was wearing a lap and shoulder belt" - which matters in court. The fix: never trust hardcoded code-to-label tables. Always read the *NAME columns directly from the source CSV, which NHTSA decodes server-side from their authoritative variable definitions.

FARS API now reads REST_USENAME, PER_TYPNAME, SEXNAME, INJ_SEVNAME, BODY_TYPNAME, and the other *NAME columns directly from NHTSA's source CSVs. We do not maintain a hardcoded lookup for any field that NHTSA already decodes.

Pre-2017 data has no decoded label columns at all

The *NAME decoded label columns we now rely on were introduced in the 2017 dataset. Pre-2017 (we sampled 2014, 2015, 2016) the CSVs only contain numeric codes for state, county, city, make, model, body type, and every other categorical field. The decoded labels you see in NHTSA's web Crash Viewer are computed at display time from internal lookup tables they don't ship with the CSV download.

If you want pre-2017 data with human-readable labels, you have to build your own code-to-label tables. NHTSA publishes the FIPS state and county codes separately, but city codes and the make/model code lists are scattered across different documents and years.

This is why we currently cover 2017-2023 in our dataset and not 2014-2023 - the marginal value of three more years of older data isn't worth the engineering work to build complete decoder tables for every categorical field.

What this means for your pipeline

If you're building your own FARS data pipeline:

  1. Read CSVs with utf-8-sig encoding to handle BOM
  2. Look up columns case-insensitively and by multiple possible names
  3. Read *NAME decoded label columns directly from source - never trust hardcoded code-to-label tables for fields NHTSA already decodes
  4. Normalize variant label wordings across years before grouping or counting
  5. Allocate at least varchar(120) for label columns - some NHTSA labels exceed 75 characters
  6. Derive crash-level drunk_drivers and hit_and_run from vehicle data (the ACCIDENT-level columns were removed in 2021)
  7. Divide ALC_RES by 1000 and filter >= 995
  8. Use VPICMODELNAME for vehicle models, not MODEL
  9. Filter lat/lon sentinel values (77.7777, 88.8888, 99.9999)
  10. If you need pre-2017 data, expect to build your own city / county / make / model decoder tables
  11. Expect columns to appear, disappear, or rename between years

Or use FARS API and skip all of this. That's why we built it.

Deep dives on specific traps

If you hit one of these issues and want the detailed explanation with exact magnitudes and SQL fixes:

API Documentation Data Coverage Details