UK Food Hygiene Rating Scheme (FHRS) Open Data

UK Food Hygiene Rating Scheme (FHRS) Open Data is the published record of the hygiene rating or inspection result given to every rated food business in the United Kingdom, reflecting the standards found on the day of inspection. The Food Standards Agency holds the data on behalf of the local authorities taking part in the Food Hygiene Rating Scheme across England, Wales and Northern Ireland, and the Food Hygiene Information Scheme (FHIS) in Scotland - roughly 380 local authority feeds pooled into a single frame.

The businesses covered go well beyond restaurants: pubs, cafes, takeaways and hotels sit beside supermarkets, convenience stores and other food shops where consumers eat or buy food. Nationally the frame runs to hundreds of thousands of establishments - Camden alone publishes 4,260 records - and a research-time probe of central London resolved 9,777 rated establishments within 2 kilometres, a density figure worth knowing before sizing any catchment analysis.

Within Datadory's catalog of 1,744 datasets averaging 7.81 on quality, this record scores 10/10: every field in the dictionary was verified against live rows during the August 2026 pass, the geographic span is national rather than city-scale, and the unit of observation - one row per rated business - matches how analysts actually ask questions. Where most inspection tables stop at a verdict, this one also publishes the component scores underneath it, which is what turns a rating into a diagnosis.

The public-facing verdict is rating_value: a number from 0 to 5 under FHRS, where 5 is the top of the scale. Under Scotland's FHIS the field instead carries a status string - Pass or Improvement Required - and businesses outside either scheme's published scope surface as AwaitingPublication or Exempt. Each value ships with a machine-readable companion, rating_key (fhrs_5_en-gb for a top-rated English premises), so downstream filters never parse display strings.

Under FHRS the published rating condenses three numeric inspection scores: hygiene, structural and confidence_in_management. The counterintuitive part is direction - lower is better, so a premises posting hygiene 0 / structural 5 / confidence-in-management 10 has performed strongly, and a 5/5/5 would be the weakest shape those fields can take. Any model or dashboard joining these columns needs that inversion handled once, at load time, not rediscovered per analyst.

Two timing fields keep the picture honest. rating_date stamps the inspection or visit that produced the result, so staleness is measurable per business rather than assumed. And new_rating_pending marks records where an authority has uploaded a fresh result still inside the notification or appeals period - the dataset's own way of saying "a change is coming" before the public number moves.

API, files, or your warehouse. Daily, weekly, or hourly.

Pick the channel your stack already speaks and set the cadence to match the decision being fed - nightly files for teams refreshing compliance dashboards, warehouse tables landing in Snowflake, BigQuery or Redshift for analysts joining ratings to their own outlet or company keys, on-demand pulls for products answering "what's the rating here" inside an app. Cadence changes are a settings conversation, not a re-integration project.

Normalization happens before anything reaches you. The roughly 380 authority feeds arrive flattened to one observation per establishment with geocodes cast as numbers, component scores typed as integers, dates typed as dates and the two identifier schemes kept distinct - so a fhrs_id join never collides with an authority-local id that has been recycled within its patch. Welsh-language variants for Welsh authorities travel alongside the English records rather than replacing them.

Every shipment includes sample rows for validation plus a coverage profile mapped to the cities, authorities and business types you named, so per-field fill rates in your market are known before a feed is committed to.

Five jobs it does better than anything else in the restaurants slice.

Enumerate the market honestly. Sales and partnership teams start from every rated food business with address, type and authority attached - a compliant base universe for the UK that predates and outlives any single commercial directory.

Chart eating-out health by geography. Market researchers break rating distributions down by nation, local authority and business type, turning "is this area's dining scene improving" into a publishable series.

Verify partners at onboarding. Marketplace and grocery-delivery operators check a listed outlet's rating and its date rather than accepting self-reported claims, catching drift between sign-up and today.

Watch rivals' ratings move. Competitive-intel teams track rating changes among monitored venues town by town - one signal among several, cheap to maintain because the identifier is stable.

Report and research with citations that hold. Journalists and academics cite the official per-business record with its inspection date, which is why this dataset scores relevance 3 across all three evidence-driven personas in the pack.

Developers & Data-Product Builders, Data Scientists & ML Engineers and Journalists & Academics all hold this dataset at relevance 3 in their restaurants packs - respectively for a documented per-establishment schema with stable identifiers, for nationwide rating series pooled across roughly 380 authority feeds, and for citation-grade food-safety facts with dates attached.

The middle tier gets real leverage at narrower depth: Sales & Growth Teams at relevance 2 for base-universe enumeration, Market Researchers & Consultants at relevance 2 for distribution charts by nation, authority and business type, and E-commerce & Marketplace Operators at relevance 2 for onboarding verification. Competitive Intelligence & Product Teams sit at relevance 1 here while leaning on place-frame datasets elsewhere in the catalog - the honest read is that this record tells you how safely a venue operates, not how busy it is.

Across all seven, the constant is authority-grade completeness: one vocabulary of business types, one identifier per premises, and every rating carrying the date of the visit that produced it.

Four things, stated plainly.

First, the rating column is deliberately mixed-typed. Numbers 0-5 dominate under FHRS, but Pass, Improvement Required, AwaitingPublication and Exempt are legitimate values in the same field, and treating the column as numeric silently drops real businesses. The sample ships with the value distribution for your named areas so the filter logic is decided up front.

Second, component scores can trail publication. Under FHRS a rescore that has been uploaded but not yet published leaves the numeric fields absent while the record remains - absence here means process, not missing data.

Third, geocodes are near-complete, not complete. Establishments operating from private addresses may lack latitude/longitude, so distance-based joins should expect a small unmatched tail; the coverage profile quantifies it per authority before any feed starts.

Fourth, two identifiers coexist by design. The system-generated fhrs_id is unique across the whole dataset, while the authority-supplied business id is unique only within its own patch and can be recycled over time - joins between systems should key on the former. Definitions here carry confidence pinned against live records during the August 2026 research pass.