Across 15,534 postings, remote engineering roles publish 11.5% lower pay than on-site ones

Last time I published what 259 companies' job boards say about pay. Two questions came out of the comments that I could actually answer with the same dataset, so I pulled a fresh snapshot (15,534 de-duplicated postings, 6,826 with a stated annual range) and looked at them.

Short version: on-site engineering roles publish an 11.5% higher midpoint than remote engineering roles at the same companies, and Lever barely publishes pay at all — 9.5% of its postings, versus 53.5% on Ashby.

First: which boards tell you the salary

This is the part I had wrong in my head before measuring. I assumed Ashby was the pay-transparent board because it returns structured salary objects. It is, but only slightly more so than Greenhouse once you read Greenhouse's job descriptions:

The denominator matters: that is every posting read from the board, not just the ones with pay. So this is a publication rate, not a composition effect.

Two practical consequences:

• Ashby gives you structured numbers (minValue, maxValue, currencyCode, interval) for half its postings. Cheap and exact.
• Greenhouse gives you almost as much coverage but as free text inside a 144 MB download of job descriptions. You have to find "the base salary range is 210,000 USD - 310,500 USD" in a wall of marketing copy, and that is where I generated three spectacular parsing bugs last time.
• Lever is where salary data goes to die. Clean schema, almost nobody uses it.

If you are building a pay dataset and you have to pick one board, pick Ashby. If you need volume, Greenhouse — and budget for the parsing.

Second: the remote gap

Overall, remote postings in this sample have a median midpoint of $191,000 against $211,500 for on-site. That is a 9.7% gap, and the obvious objection is composition: maybe remote postings are concentrated in lower-paying functions.

So I compared remote and on-site within the same role family, requiring at least 60 postings on each side:

The gap survives controlling for function. It is biggest in support/ops and in the catch-all bucket, solid in engineering, and it reverses for sales — remote sales roles publish 6.1% more, which makes sense if you think of remote sales as covering bigger or more scattered territories.

What I cannot tell you

I can't separate two explanations, and I want to be blunt about it:

1. The same job pays less when it is remote. Companies discount for location independence.
2. Remote roles are open to cheaper geographies, so the published range reflects a national or global band rather than a San Francisco one.

Both produce exactly the pattern above. The dataset has a location column, and you could partly untangle it by splitting "remote (US)" from "remote (anywhere)" — but a large share of postings just say "Remote" with no country, so any split I do here would be me assigning geography by vibes. Not doing that.

There is also a smaller caveat: medians mix seniority. A company posting mostly staff-level on-site roles and mostly mid-level remote ones would show this gap without any remote discount existing. I have title, so a title-based seniority regex is the obvious next step, and it is on the list.

The part that is actually useful

If you are negotiating a remote offer, the interesting number is not "what do remote roles pay" — it is what does this company publish for the on-site version of my job. That is a concrete anchor, it comes from the same salary band, and it is a legitimate question: "I noticed the on-site posting for this role has a higher band; is the remote band adjusted for location, and if so, to what?"

In engineering the median difference at these companies is $26,906. That is worth one email.

Get the data

Same free CSV as before, refreshed: 1,459 rows, stratified so all 259 companies appear, CC BY 4.0, no signup:

• CSV: https://sjdfi0wjvosdju9.github.io/data/salary-ranges.csv
• Page with the method, per-company medians and the full tables: https://sjdfi0wjvosdju9.github.io/salary-data.html
• Stats as JSON, if you want to check my arithmetic: https://sjdfi0wjvosdju9.github.io/data/salary-stats.json

The remote column is yes/no straight from the board, and role_family is my own regex over the title — so treat the family table as indicative, not as a classification anyone agreed on.

If your own company contradicts the engineering number, I would like to hear it. One counter-example with a real band is worth more than my median.

Numbers revision (2026-10-24): the pipeline was merging distinct city-level requisitions under one title, so row counts here are lower than the current dataset. After fixing the dedupe key the same 259 companies yield **18,567 postings / 7,984 with published pay* (median $200,000). The current figures live on the dataset page; the bug is written up here.*

Numbers revision (2026-10-24, role classifier fix)

The role-family buckets in the earlier numbers came from a single-tier classifier
that matched engineer before anything else, so Sales Engineer, Solutions
Engineer and Support Engineer were all counted as engineering, and the word
data pulled data-center technicians into data/ML. That is also why other
reached 21.5% of rows.

Rebuilt with a four-tier classifier (disambiguation -> specific -> generic ->
broad) and 21 unit tests. Same 8,041 rows; only the buckets moved:
engineering 39.7% -> 27.4%, sales 10.8% -> 15.4%, support / ops 6.3% -> 15.2%,
finance / legal 3.3% -> 9.1%, other 21.5% -> 8.5%.

Consequence for the remote-vs-on-site gap: engineering was -11.5%; after the
fix it is -6.2% (remote median $212,000 vs on-site $226,000, n=563 / 1,638).
The direction holds, the magnitude shrinks. Current numbers:
https://sjdfi0wjvosdju9.github.io/salary-data.html