Methodology
How these pages are built
Every number on this site is an aggregate of public disclosure records. This page states exactly which records, exactly what we do to them, and — just as important — what we refuse to do to them.
Sources
Two federal datasets. No scraped job boards, no user submissions, no estimates.
US Department of Labor, OFLC disclosure data
The quarterly Labor Condition Application disclosure files published by the Office of Foreign Labor Certification. One row per LCA: employer, worksite, job title, SOC occupation code, offered wage, prevailing wage and level, case status, and the worker-position counts. This is the source of every filing count, wage distribution, job title and worksite on the site.
Covers FY2026 onward, which is where the current column layout begins.
USCIS H-1B Employer Data Hub
Petition-level approvals and denials, split into initial and continuing, per employer per fiscal year. An LCA is a labor filing; a petition is the actual immigration request. Where an employer matches, the approval rate we show is computed from these petition counts and labelled as such — the DOL case status is a different measurement and is never blended with it.
Both datasets are US Government works and are in the public domain.
How employer names are canonicalized
Exactly four operations. There is no fifth.
- 1
Unicode NFKC normalization
Compatibility-composed form, so a full-width character, a ligature and a non-breaking space resolve to their ordinary equivalents. Two records that differ only in encoding are the same string afterwards.
- 2
Trim and collapse whitespace
Leading and trailing whitespace removed, runs of internal whitespace collapsed to a single space. “ACME CORP ” and “ACME CORP” are the same employer.
- 3
Case-fold for the key
The lookup key is case-folded, so “Acme Corp” and “ACME CORP” land on one page. The displayed name keeps the casing DOL published.
- 4
Normalize punctuation around the legal suffix
“X, INC.” and “X Inc” differ only in a comma and a period, so they resolve to one entity. The suffix itself is never removed — see below.
What canonicalization deliberately does not include
- No suffix stripping. “X Inc” and “X LLC” stay separate. They are separate legal entities, they file separately, and they are often genuinely different businesses.
- No fuzzy matching. No edit distance, no token overlap, no phonetic keys, no vector similarity.
- No model judgment. A language model is never asked whether two names are the same company.
- No parent-company roll-up. A subsidiary that files under its own name has its own page, and its numbers are never folded into the parent’s.
We do compute a loose name grouping, and it is used for two things only: to populate search suggestions, and to show a “possibly related” list on an employer page so you can check for yourself. It never affects a single number.
Why employers are never merged
The employer name on the filing is the entity. A worked example.
Every dataset like this faces the same temptation: the names are messy, so clean them up and combine what looks like the same company. Here is what that costs. Three employers in the DOL file begin with the same word:
| Employer name, as filed | Employer address | NAICS | Industry | What they actually do |
|---|---|---|---|---|
| Greenpoint Technologies Inc | Kirkland, WA | 3364 | Aerospace product and parts manufacturing | Interiors for wide-body aircraft |
| Greenpoint IT LLC | Cary, NC | 5415 | Computer systems design and related services | IT staffing and consulting |
| Greenpoint Consultation Center | Brooklyn, NY | 6214 | Outpatient care centers | Healthcare practice |
Any name-similarity step aggressive enough to merge these produces one page with one wage distribution covering aerospace manufacturing engineers, contract IT staff and a healthcare practice’s administrators. The median it reports would describe no one. The industry would be wrong for at least two of the three. And an H-1B dependency or willful-violator flag belonging to one of them would be displayed against all three, which is not just imprecise — it is defamatory about two companies that did nothing.
So the rule is absolute: the canonicalized employer name is the entity. If you believe two of our pages are the same company, compare the address, the NAICS code and the point of contact yourself. We give you those fields on every page precisely so that judgment stays yours.
The trade-off is honest and worth naming: an employer that filed under two spellings has two pages, and each shows a lower count than the company’s true total. We would rather undercount one employer than publish a merged number that is wrong for three.
Filings are not headcount
The single most common misreading of this data.
A filing covers positions
Each application declares a number of worker positions — sometimes one, sometimes fifty. We count positions and filings separately and label both. Neither is a person.
Renewals are counted again
A continued-employment filing is an existing employee whose status is being extended — the same person, a second time. An employer that renews 100 people every three years generates the same volume as one hiring 100 new people.
Certification is not a hire
A certified LCA is permission to petition. The role may never be filled, the petition may be denied, and the lottery may not select it.
What follows from that
- Position counts are never summed across fiscal years. Adding FY2024 and FY2025 would count every renewed worker twice, and the result is not a headcount at any scale.
- Where a page says “new positions”, it means new-employment filings in a single fiscal year. If we cannot compute that for an employer, the page shows a dash — never a lifetime total under a twelve-month label.
- Approval rates come from petition outcomes, not filing volume. A withdrawn application is excluded from the denominator rather than counted as a denial.
What is stored and what is computed
Components are stored. Every ratio is derived when the page renders.
We store counts, never ratios: approvals and denials as separate numbers, and offered wages as counts in $5,000 bands. Approval rates and wage percentiles are computed at read time from those components.
This is not an implementation detail — it is what makes a multi-entity comparison correct. If we stored a median per employer, comparing five employers would mean averaging five medians, which answers no question. Because we store the bands, comparing five employers adds the bands together and takes the percentile of the combined distribution, which is the real one.
Percentiles are interpolated within a band, so a median reads as a point inside a $5,000 range rather than as an exact salary anyone was paid.
Privacy: position-level only
There is no worker in this dataset, and we do not invent one.
DOL publishes these files with all worker personal information removed. A record describes a position at an employer: an occupation, a worksite, a wage, a date range. There is no name, no identifier and nothing that distinguishes one worker from another — which also means there is no way to tell whether two filings refer to the same person.
We keep it that way. No worker identifier is synthesised, no records are linked across filings to reconstruct an individual’s history, and nothing on these pages is about a person. Everything published is an aggregate at the employer, occupation or location level.
Small samples are labelled rather than dressed up: a wage distribution built from fewer than 5 disclosed positions is presented as an anecdote, not as a range, because at that size a percentile is one employer’s single offer rather than a market rate.
Wages shown are the offered wage on the application, which is a term of the employer’s filing — not anyone’s actual compensation, bonus or equity.
Refresh cadence and coverage
Quarterly
DOL publishes the disclosure file once per fiscal quarter, roughly two months after the quarter closes. We reload the whole corpus each time it appears and rebuild every page from scratch — there is no incremental patching, so a correction DOL makes to an old record propagates.
Current data: FY2026 Q2, covering applications through . Between loads, these pages do not change.
Which employers get an indexed page
An employer page is offered to search engines only if the employer has at least 5 lifetime filings and has filed at least once in the last 24 months. Everything below that threshold still has a page, still shows its real numbers and is still linked — it is simply marked noindex, follow.
A company with two filings from five years ago has nothing useful to tell a job seeker about sponsorship today, and publishing thousands of such pages into an index is how a real dataset gets treated as filler.
Corrections and limits
We do not edit the source records. If a filing has a typo in the employer name, a wrong NAICS code or a worksite in the wrong city, that is what the government file says and that is what appears here; the fix has to happen at DOL. What we will fix is our own aggregation — a mis-parsed column, a bad slug, a page that shows the wrong entity’s data.
Nothing here is legal or immigration advice, and none of it predicts whether any employer will sponsor you. It is a record of what employers filed.
Start from the H-1B data home or go straight to all companies.