Contact Us

Feedback is welcome. Please write us at

1. Scope

The public-use data from the Longitudinal Employer-Household Dynamics Program, including the Quarterly Workforce Indicators (QWI) and Job-to-Job Flows (J2J), are available for download according to structural and file naming schema. The data themselves are available as Comma-Separated Value (CSV) files through the LEHD website’s Data page at as well as through the LED Extraction Tool.

Shapefiles are used to provide mapping functionality in QWI Explorer and Job-to-Job Explorer. They are created by transforming input shapefiles sourced from TIGER/Line. New TIGER/Line shapefiles are typically released by the Census Bureau’s Geography Division in August of each year, which are then processed by the LEHD program as new tabulation areas for the QWI and J2J data products.The LEHD shapefiles will be made available in the data schema in coordination with the public release of QWI and J2J data products, usually in December or January of each year.

2. Sources

Files are derived from TIGER/Line 2023 shapefiles:

3. Transformations

The following major transformations are applied to the input files:

  • All geographies are reprojected to WGS-1984 Geographic Coordinate System

  • Shoreline water has been clipped out to provide a more recognizable depiction of the coastlines.

  • Each layer is given internal point coordinates (stored as double) based on the WGS-1984 projection (decimal degrees).

  • Features from Guam, American Samoa, and the Northern Mariana Islands have been removed because they are not used in current LEHD tabulations.

  • Some uninhabited Hawaiian islands and select Alaskan islands crossing the 180th meridian have been removed.

  • Each shapefile’s attribute table has been updated to conform to the standard LEHD output format, defined in Format section

4. Outputs

Output shapefiles – grouped by paired products – are listed below.Each shapefile includes specific notes on its preparation.

5. Basic Naming Schema

All files follow the following naming convention:


where [type] = lehd_shp and geocat contains

type Description


Metropolitan (complete)




Metropolitan/Micropolitan (state parts)


National (50 States + DC)




Workforce Investment Areas

5.1. Format

Files are distributed as ESRI Shapefiles, packaged as ZIP files. The SHP component of these archives is described here. Other components (dbf, prj, shx) files are not documented here, we refer users to .

column label description type


State USPS code

FIPS State Postal Code as per



Nationally unique identifier

Derived from Nationally Unique Federal Information Processing Series (FIPS) Code as per (see notes)



Feature Name

Full Census Name of Geography Feature



Feature Label

Shorter Census Name of Geography Feature for Thematic Mapping



Internal Point Latitude

Internal Point Latitude in WGS-1984 Decimal Degrees as per



Internal Point Longitude

Internal Point Longitude in WGS-1984 Decimal Degrees as per


5.2. Values

5.2.2. Geography

The valid codes correspond to those listed on label_geography.csv.

5.2.3. Name

This is a string that corresponds in general to the 'label' field on label_geography.csv. Minor deviations for ease of exposition are possible.

5.3. Common Files

5.3.1. State

No transformations occur to this layer other than those listed above.

5.4. QWI Geographies

5.4.1. County

  • STUSPS is appended to the NAME field so that county names are nationally unique. Example: "Cook, IL"

5.4.2. CBSA (within State)

5.4.3. Workforce Investment Board Areas

The WIA/WIB shapefiles are built from the Place, County Subdivision, and County shapefiles from TIGER/Line based on definitions provided by the LED state partners.

5.5. Job-to-Job Flow Geographies

5.5.1. Metropolitan (Complete)

  • Micropolitan areas are removed and state remainder areas are added as new features. State remainders are assigned unique codes ([STUSPS]+999) and names ("Not in metropolitan area, [STUSPS]").

6. Versioning

Versioning rules follow Semantic Versioning V2.0.0, which states that

Given a version number MAJOR.MINOR.PATCH, increment the:

  • MAJOR version when you make incompatible API changes,

  • MINOR version when you add functionality in a backwards-compatible manner, and

  • PATCH version when you make backwards-compatible bug fixes.