Paste a Glassdoor jobs search and get its results back as a table - the title, the company, the location, the advertised salary, the listing link and a snippet of the description, each row tagged with the position it held in the results.
Most pages here quote fill rates from thousands of rows across many inputs. This one cannot, and pretending otherwise would be the easiest way to mislead you.
Our evidence is one populated run of 100 rows from a single Glassdoor search. Five further runs returned nothing at all. The twelve column names are solid - the spreadsheet header and the JSON keys match exactly and are identical across all six runs - but any statement about how often a column is filled describes that search, not the service.
That distinction matters more than it might sound. Two columns were perfectly constant in our data: company_rating was empty on every row, and easy_apply read Yes on every row. Either could be a property of the service, or simply a property of the search we happened to run. We cannot tell from one query, so we do not claim either.
There is also no published reference for this endpoint - Glassdoor does not appear anywhere in the API documentation. So unlike the other scrapers on this site, this page quotes no batch limit, no language or region setting and no sort order, because there is no source for any of them. What follows is what we saw, and nothing else.
What we ran was a Glassdoor jobs search URL, and the results came back as rows.
Build the search on Glassdoor first, with the filters you want, then submit that URL. The filters you set there are what shapes the result set.
The names are the export header, matching the JSON keys exactly and identical across all six runs. The counts beside them come from our single populated run of 100 rows - treat them as one observation, not a rate.
$120K - $170K (Employer provided). On all 100 of our rows, though see the note below before assuming that holds generally.30d+, 24h or 13d. Never an actual date. On 71 of our 100.Yes on all 100 of our rows - which, from a single search, tells us less than it appears to.The names are verified; the counts are one search. The spreadsheet header equals the JSON keys exactly and is the same in all six runs, so the twelve columns are real. Everything else on this page came from a single 100-row export, and the free tier is the honest way to find out how your own search behaves before you build on it.
Two of these hold whatever you search for. Two are warnings about reading too much into a single run - including ours.
Our 100 rows held only 53 distinct job_url values. Twenty-seven links appeared more than once, one of them four times, each at a different position. So a row count is not a listing count. Deduplicate on job_url before you report how many jobs a search found, or you will overstate it by roughly half.
The values we saw were 24h, 3d, 13d, 30d+ and similar - a relative age at the moment of the run, not a timestamp. It cannot be parsed as a date, it cannot be sorted meaningfully against a different run, and 30d+ is an open-ended bucket rather than a value. If you need real dates, record the run date yourself and derive them.
Every salary in our export ended with its provenance: 96 of 100 said (Employer provided) and the rest (Glassdoor est.). That distinction matters - one is what the employer wrote, the other is a model's guess - and it is inside the same string as the range, so parse it out rather than discarding it. Whether salary is this well populated on other searches, we cannot say from one.
company_rating was empty on every row and easy_apply read Yes on every row. A search filtered to one-click applications would produce exactly that second pattern, and so would a column that always says Yes. One query cannot separate the two. Check both on your own first export rather than taking ours as the rule - that is the whole reason the free tier exists.
What a ranked, exportable search is good for.
Because salary carries its provenance in the same string, you can separate what employers actually published from what Glassdoor estimated. A benchmark built only on employer-provided figures is a very different - and more defensible - number than one that mixes in model output.
The position column records the order the results came back in. For anyone advertising a role, that is the difference between being on the board and being seen on it - and re-running the same search URL turns it into a movement you can track.
Our single search of 100 rows covered 31 distinct companies hiring for one role in one city. Deduplicated on employer, that is a ready-made list of who is active in a market right now - a better starting point than a directory that may be years out of date.
No subscription, no minimum, no per-seat licence. Your first 500 rows are on us - after that, pay-as-you-go.
Every new account, one-time. No credit card required. All scrapers unlocked. On this service in particular the free rows are the point: one search of your own tells you what our single export could not.
Roughly $2 per 1,000 rows. Worth remembering that rows are results rather than distinct listings - ours were about half duplicates - so budget on the result count you see, not on the number of jobs you expect.
Volume pricing, SLAs, dedicated workers and bespoke onboarding for teams tracking hiring across many searches and markets. Tell us your numbers and we'll quote.
LIVESCRAPER10 at checkout.Glassdoor is one of several places a role gets advertised, and the overlap is rarely complete.
Google's aggregated jobs panel pulls from many boards at once, and names the source of each posting. The wider view around this one.
One employer's own board in full depth - complete descriptions, qualifications and responsibilities rather than a snippet.
Short answer: yes. These are adverts, published to be found by as many people as possible.
A jobs search page is public. Anyone can browse it without an account, and collecting publicly visible listings for research is long-established practice. As long as the data is publicly available and the process doesn't disrupt the site there are no federal laws prohibiting it.
Job adverts sit comfortably here. The subject of a listing is a role at a company, not a named individual - nothing in these twelve columns describes a person. There is no login, no paywall, and nothing is applied to on your behalf.
Glassdoor's terms restrict automated access, so this remains a terms question. We touch nothing behind a login, run no third-party trackers on the data layer, and your exports auto-delete after 30 days.
The questions we hear most. Anything else? Talk to us - humans, not bots, write the answers.
query, job_title, company, company_rating, location, salary, date_posted, easy_apply, job_url, snippet, logo and position. Those names are solid - the spreadsheet header matches the JSON keys exactly and is identical across all six of our runs. How often each is filled is a separate question, and one we can only answer for the single search we ran.easy_apply read Yes on every row we saw - but our evidence is one search, and a search filtered to one-click applications would look exactly the same as a column that always says Yes. We are not going to guess which. Treat it as unverified until your own export shows otherwise.job_url values, with 27 links repeating and one appearing four times. Deduplicate on job_url before counting jobs, and remember that billing follows rows rather than distinct listings.date_posted is a relative age at the moment of the run - 24h, 13d, 30d+ - rather than a date, and 30d+ is an open bucket with no upper edge. If you need real dates, store the date you ran the job and subtract.Paste a Glassdoor jobs search URL and get its results back as ranked rows. Your first 500 rows are free - which on this service is genuinely the right way to start.
Glassdoor's jobs search is built for browsing: you scroll, you click, and the ordering that determined what you saw disappears the moment you leave the page. The Glassdoor Job Scraper takes a search URL and returns its results as a table instead - one row per result, carrying the job title, the company, the location, the advertised salary with its source, the listing link, a snippet of the description, the company logo, and the position the result held in the ranking. Build the search on Glassdoor with whatever filters you want, submit the URL, and take the results away as CSV, JSON or Excel.
This page is more cautious than the others on this site, and the reason is worth stating up front. Our evidence is a single populated run of 100 rows from one search; five other runs returned nothing at all. The twelve column names are firm - the spreadsheet header matches the JSON keys exactly and is identical across all six runs - but every count beside them describes that one search rather than the service. There is also no published reference for this endpoint: Glassdoor appears nowhere in the API documentation, so this page quotes no batching limit, no language or region setting and no sort order, because no source for them exists. Where other pages here can tell you what happens across thousands of rows and many inputs, this one can tell you what happened once, and says so.
Two findings hold regardless of what you search for. The first is that rows are not listings: our 100 rows contained only 53 distinct job URLs, with twenty-seven links repeating and one appearing four times at different positions, so any count of jobs must deduplicate first - and billing follows rows, not unique roles. The second is that date_posted is an age rather than a date. The values were 24h, 3d, 13d and 30d+, measured at the moment of the run, which means they cannot be parsed as dates, cannot be compared across runs, and in the case of 30d+ have no upper bound at all. If you need real dates, record when you ran the job and derive them.
Two more findings are genuinely interesting and genuinely unresolved. Salary was present on every row of our search, always with its provenance appended - 96 of 100 marked employer provided and the remainder a Glassdoor estimate - which is a distinction worth parsing out rather than discarding, since one is what a company published and the other is a model's guess. But company_rating was empty on all 100 rows and easy_apply read Yes on all 100, and a single query cannot tell you whether those are properties of the service or artefacts of the search we happened to run. A search filtered to one-click applications would produce exactly the pattern we saw. We are not going to resolve that by guessing, so the recommendation is concrete instead: run one search of your own against the free 500 rows and look at those two columns before you build anything that depends on them. Your first 500 rows cost nothing and need no credit card.