License-Plate Recognition (LPR / ANPR)

This is engineering guidance, not legal advice. Confirm specifics with qualified counsel.

Why this matters

License-plate recognition is the analytic most likely to be deployed casually and regretted later — not because the technology is exotic, but because buyers underestimate both how conditional its accuracy is and how quickly stored plate-reads turn into a map of where people go. The person specifying it is usually a parking operator, a security integrator, a city traffic or enforcement lead, a logistics or campus manager, or a product owner who watched a demo read a plate cleanly in a sunny lane and now has to size a system for rain, headlights, speed, and a hundred plate designs. This article is written so a non-technical reader can understand both halves: how the read actually works and where it falls down, and why a plate is legally a different animal from a face — lighter in one respect (it is not biometric) and heavier in another (it builds location histories). A senior video engineer will find the standards and accuracy framing precise; the writing serves the decision-maker first.

What LPR is — and the words people mix up

Start with the names, because three acronyms describe the same idea and a fourth is quietly different. LPR (License-Plate Recognition) and ANPR (Automatic Number-Plate Recognition) are the same technology — LPR is the common term in North America, ANPR in the UK and much of the world. ALPR (Automated License-Plate Reader) usually names the law-enforcement and mass-collection version of the same thing. All three mean: a camera and software that read a vehicle's plate from video and turn it into searchable text.

The fourth word matters for buying the right camera. LPC — License-Plate Capture — means a camera that records a clear, legible image of the plate for a human to read later, but does not convert it to text. LPR adds the recognition step that outputs the characters as data a computer can match, search, and alarm on. A capture camera gives you evidence; a recognition camera gives you automation. Knowing which you are buying prevents the most common procurement mistake in this field.

One more framing that keeps the whole article honest: LPR identifies a vehicle, and through a registration database its registered keeper — not necessarily the person driving. A plate read says "this car passed here at this time," not "this individual was here." That gap — vehicle, not driver — runs through both the accuracy story and the privacy story below.

How LPR works: the four-step pipeline

Modern license-plate recognition is a four-step assembly line. Each step is where accuracy is won or lost, so each is worth understanding plainly.

Step 1 — Find the plate (detection). First the system locates the vehicle and the plate within the frame, the same way the object detection we covered earlier draws a box around a car or a person. A neural network trained to spot plates returns a box around the plate region. If the plate is too small in the frame, too angled, or lost in glare, everything downstream suffers — garbage in, garbage out starts here.

Step 2 — Clean the image (preparation). The cropped plate is rarely straight-on or evenly lit. The system rotates and straightens it (deskew), scales it to a standard size, and boosts contrast so the characters separate from the background. This is where the special hardware earns its keep: a plate's retroreflective coating — the same material that makes road signs glow in headlights — bounces infrared light straight back to the camera, so an infrared illuminator makes the characters stand out even in complete darkness. Clean the image well and the reader's job becomes easy; clean it poorly and no reader can rescue it.

Step 3 — Read the characters (OCR). Now the core step: optical character recognition, the technology that converts a picture of text into actual letters and numbers. The system either segments the plate into individual characters and recognizes each one, or — in newer designs — reads the whole plate in one pass with a neural network trained on many plate fonts and layouts. The output is a string like AB12CDE. The model internals here — the OCR network architecture and training — belong to the AI for Video Engineering section; this article owns how that read plugs into a camera, a VMS, and a workflow.

Step 4 — Check the result (post-processing). A raw read is not trusted blindly. The system applies the syntax rules of the expected region (a UK plate has a fixed letter-number pattern; a US state plate has its own), uses multi-frame voting — reading the same plate across several video frames and taking the most consistent answer — and then matches the confirmed plate against a watchlist (vehicles of interest) or an allowlist (permitted vehicles, e.g. residents). The whole pipeline, from image to matched result, typically completes in well under a second.

Figure 1. The capture-to-character pipeline. A plate is detected and cropped, cleaned and deskewed (infrared makes the retroreflective plate readable in the dark), read by OCR into a character string, then validated against regional syntax and multi-frame voting before being matched to a watch- or allowlist. Accuracy is won or lost at every step — most of all at capture.

Accuracy is two numbers, not one

Here is the rule the whole section is built on, applied to plates: accuracy is a range tied to image quality, angle, speed, lighting, and plate condition — never a single number, and never 100%. And for LPR there is a second, sharper point that most vendor datasheets blur: there are two accuracy numbers, and the honest figure is their product.

Capture rate answers: of the vehicles that passed, on how many did the camera get a usable image of the plate? A vehicle can be missed because it was occluded by another car, the plate was outside the frame, the exposure was wrong, or the trigger fired late. Manufacturers commonly target capture rates around 98%.

Read rate answers: of the plates that were captured, how many did the OCR turn into the correct characters? A captured-but-misread plate confuses an 8 for a B, drops a character, or mangles a non-standard font. Manufacturers commonly target read rates around 95%.

Now the arithmetic that buyers skip. The end-to-end system accuracy is the two multiplied:

• capture rate: 98% = 0.98
• read rate: 95% = 0.95
• overall correct reads: 0.98 × 0.95 = 0.931 → about 93%

So a system advertised with two excellent-sounding numbers delivers correct, usable reads on roughly 93 in 100 vehicles in good conditions — and that is the good case. Quote a single "99%" and you have hidden which of the two numbers it describes, and under what conditions it was measured.

Figure 2. The two numbers, multiplied. Every vehicle passes through two gates: capture (did the camera image the plate?) and read (did the OCR get the characters right?). The system accuracy is the product, not either number on its own — about 93% from a 98% capture and a 95% read. A single advertised "accuracy" usually names just one gate.

Conditions move both numbers, hard. The factors that matter most, in rough order: the angle of the plate to the camera (keep it within roughly 30 degrees horizontally and vertically), the vehicle's speed (faster means more motion blur unless the shutter is fast enough to freeze it), lighting (direct sun, headlight glare, and total darkness each defeat a camera not built for them), the plate's physical condition (dirt, damage, tinted covers, unusual fonts), and plate diversity (a US deployment faces 50-plus state designs and vanity plates; a standardized single-country plate is far easier). A controlled parking lane — slow vehicles, a fixed good angle, infrared at night, mostly local plates — lands near the top of the range, commonly 95–99% read rate. A free-flowing multi-lane road, mixed weather, mixed plates, and higher speeds pulls the real-world figure down, sometimes well below the lane number, which is why tolling and enforcement programs treat misreads as a budgeted cost, not an impossibility.

Figure 3. Accuracy by condition. A controlled access lane (slow, good angle, IR at night, local plates) commonly reads 95–99%; free-flow traffic with mixed weather, angles, speeds, and plate designs falls below that, by a margin that depends on the scene. The dashed line marks the rule: never 100%. Angle, speed, light, plate condition, and plate diversity each move the number.

A common mistake to avoid

The costliest pattern we see is treating a plate read as proof a person was somewhere. A plate identifies a vehicle and, via a registry, its registered keeper — not the driver, and not with certainty when a character was misread. The runner-up is specifying with the lane number and deploying onto a road: the 98%-capture / 95%-read figures from a slow, well-lit access point are not what a four-lane highway at dusk delivers, and budgeting on the demo number guarantees disappointment. The third is buying a capture (LPC) camera and expecting recognition (LPR) — or buying a general camera and bolting on LPR without the infrared, the fast shutter, and the tight angle the read actually needs. Demand a field pilot on your real cameras, your real traffic, and your real plate mix, reported as separate capture and read rates with the conditions stated, before anyone calls LPR "done."

What the read needs from the camera

Plate recognition asks more of the camera than ordinary surveillance, and a dedicated LPR camera is built around four things general cameras get wrong.

The first is a fast shutter. A vehicle at road speed moves far enough during a normal exposure to smear the plate into an unreadable blur, so LPR cameras use short exposures — commonly in the range of 1/500 to 1/2000 of a second, faster still for high speeds — to freeze the plate. The second is infrared illumination tuned to the plate's retroreflective coating, which returns a crisp, high-contrast plate image in full darkness and cuts through headlight glare, while the rest of the scene stays dark. The third is a tight, controlled field of view: a varifocal or long lens that fills the frame with the plate at the read point, because resolution spent on the plate is resolution that helps the OCR. The fourth, on cameras built for fast lanes, is a global shutter sensor that exposes the whole frame at once, avoiding the diagonal smear a rolling shutter produces on fast objects and synchronizing cleanly with the infrared pulse.

The practical consequence: LPR is usually a dedicated camera aimed at the read point, often paired with a second context or overview camera that shows the whole scene — the driver, the lane, the surroundings — in normal color. The LPR camera answers "what plate?"; the context camera answers "what happened?". Trying to do both jobs with one camera is the quiet reason so many retrofit LPR projects underperform.

Where LPR runs — and how the plate reaches the VMS

The pipeline can run in two places, and where it runs shapes cost, latency, and privacy. On the edge, the camera or a small on-site box reads the plate itself and emits only the result — the plate string and a thumbnail — which keeps bandwidth low and the raw video local. Many modern LPR cameras are self-contained readers that do the whole pipeline on-device. Centrally, on a server or in the cloud, the camera sends frames up and the read and the database matching happen in one place — which is what you need to match a plate against a large, frequently updated hotlist or to correlate reads across many cameras. Where analytics run — camera, on-site server, or cloud — is its own decision with its own latency, bandwidth, and privacy profile, covered in edge vs cloud video analytics. This article owns what LPR does and what law wraps it.

However it runs, the read becomes useful only when the Video Management System — the software that ingests and records many camera streams, called a VMS — can receive and act on it. That is where the standard comes in. ONVIF is the common language that lets cameras and software from different makers understand each other, and ONVIF Profile M is the profile built for analytics metadata and events. Profile M explicitly defines standardized metadata for license plates (alongside vehicle, face, and body) and an event interface for license-plate-recognition analytics, carried inside the video stream, through the ONVIF event service, or over the lightweight messaging protocol MQTT (ONVIF, Profile M). Its own example use case is "access control in a parking lot through license-plate-recognition apps." That standardized event is why a Profile M camera's plate reads can open a gate, fill a search index, or raise an alarm in a Profile M VMS from a different vendor.

Here is the boundary that catches teams out, and it is the same one that governs every analytic. ONVIF standardizes how a plate event is reported, not how accurate the read is or how it was computed. The OCR model, the confidence threshold, the regional syntax rules — those are the vendor's own, reached through their SDK, not guaranteed by ONVIF. As always, ONVIF conformance is a baseline for interoperability, not a promise of feature parity or accuracy. Keep "ONVIF-conformant plate events" and "accurate plate reading" firmly separate. For the standard beneath this, see events, metadata, and the ONVIF analytics interface; for the commercial overview of how the profiles fit security systems, Fora Soft's ONVIF profiles in security systems is the reference.

Figure 4. Where it runs and how it surfaces. Edge LPR reads on the camera and sends only the plate string and thumbnail; central LPR sends frames up to match against a large hotlist and correlate across cameras. Either way the read enters the VMS as an ONVIF Profile M license-plate event — the standardized channel, which carries the event, not a guarantee of its accuracy.

The legal line: a plate is personal data, but not biometric

This is the part that separates license-plate recognition from face recognition, and getting it right protects you from both over-caution and complacency. With faces, the law comes before the feature because a face template is biometric data. A license plate is different.

A plate is personal data. Under the EU's General Data Protection Regulation, personal data is any information relating to an identified or identifiable person, including an identification number. A plate, processed in a context that links it through a registry to the vehicle's keeper, is personal data — so GDPR applies: you need a lawful basis, you must tell people the system exists, and systematic monitoring needs a risk assessment (GDPR, Reg. (EU) 2016/679, Art. 4(1) and Art. 6; EDPB Guidelines 3/2019 on video devices).

A plate is not biometric data. This is the crucial distinction. Biometric data, in the GDPR's Article 9 sense, results from technical processing of a person's physical characteristics — a face, a fingerprint, an iris — to uniquely identify that person. A plate is an assigned identifier of a vehicle, not a measurement of a body. The European Data Protection Board treats license plates as a separate category of personal data from biometric data. The practical upshot: the special-category Article 9 regime, and the US biometric statutes built around it — Illinois' BIPA, Texas' CUBI — that gate face recognition do not attach to the plate itself. LPR clears a lower legal bar than face matching. That is a real and useful difference, and it is why parking lots run LPR freely where they could never run face recognition.

But the real risk is the movement profile. The danger in license-plate recognition is not a single read; it is the history. Store every read from many cameras over months and you have built a map of where a vehicle — and by inference its owner — has been, when, and how often. That aggregation is the heart of the privacy concern, and it is why mass automated plate-reading draws sustained scrutiny. The Electronic Frontier Foundation's analysis of police reader networks found that more than 99.9% of the plate data collected is unconnected to any crime or investigation — it is, overwhelmingly, a record of innocent people's movements held just in case (EFF, Street-Level Surveillance: Automated License Plate Readers). The legal gate for LPR, in other words, is mostly about retention, access, and sharing, not about consent to capture.

Three regimes show how that plays out, and they differ by place:

• European Union — GDPR + the EDPB. A plate is personal data; an ANPR deployment needs a lawful basis (for paid parking, often the necessity of performing a contract; for public bodies, a public-task or legitimate-interest basis), clear signage, data minimization, a defined retention period, and — for systematic monitoring of a public space — a Data Protection Impact Assessment under GDPR Art. 35, as the EDPB's video-devices guidance spells out (EDPB, Guidelines 3/2019).
• United Kingdom — one of the world's largest ANPR networks, tightly governed. The UK's national ANPR capability records on the order of 60 million reads a day, retains data for 12 months, and restricts access through role-based controls; its operation is documented in a published Data Protection Impact Assessment and governed by the Information Commissioner's Office guidance and the Surveillance Camera Code of Practice issued under the Protection of Freedoms Act 2012 (UK Home Office, National ANPR Service DPIA; ICO, ANPR guidance). Scale and oversight rise together by design.
• United States — no federal law, a state patchwork. ALPR is widely deployed with little federal regulation. California's SB 34 (2015, codified at Civil Code §1798.90.5 et seq.) is the leading example of a state safeguard: it requires ALPR operators to publish a usage-and-privacy policy, keep access logs, secure the data, and — for public agencies — bars selling or sharing the data except to other public agencies. Reader data is often retained for years and frequently held in private databases run by vendors such as Flock Safety or Motorola's Vigilant, and enforcement actions over unlawful data-sharing are ongoing (California Civil Code §1798.90.5; EFF, ALPR policies).

The clean engineering rule that falls out of all three: for license plates, design to the retention and sharing law, the way you design to the biometric law for faces. Set a defined, defensible retention period and delete on schedule; log and limit who can query the history; don't share the data outside its lawful purpose; post notice; run the DPIA for any systematic deployment. The plate is easier to capture lawfully than a face — and the stored history is where the liability actually lives. This is engineering guidance, not legal advice.

Figure 5. The legal line. A face crosses into Article 9 biometric data (consent, BIPA/CUBI); a plate does not — it is ordinary personal data identifying a vehicle and its keeper. So LPR's gate is data-protection and retention law: GDPR + a DPIA (EU), the ICO and Surveillance Camera Code (UK), and SB 34 and the state patchwork (US). The real risk is the stored movement profile, not the single read.

LPR at a glance

	License-plate recognition (LPR / ANPR)	Face recognition
Identifies	A vehicle, and via a registry its keeper	A specific named person
Reads from	The plate — assigned text on metal	The face — a measured body characteristic
Data type	Personal data (not biometric)	Biometric, special-category
Primary legal gate	Retention, access, sharing (GDPR, SB 34, ICO)	Consent + biometric law (Art. 9, BIPA, CUBI)
Two accuracy numbers	Capture rate × read rate	Detection, then 1:1 / 1:N match
Best conditions	Slow lane, good angle, IR, local plates	Cooperative, lit, frontal
Where it runs	Edge camera or server / cloud	Edge detect, server/cloud recognize
Surfaces in VMS as	ONVIF Profile M license-plate event	ONVIF Profile M recognition event

Table 1. License-plate recognition versus face recognition. They share a camera-to-event shape and the "never 100%" accuracy rule, but they are legally different: a plate is personal data under retention law, a face is special-category biometric data under consent law. Match the analytic — and its legal gate — to the actual job.

Where it earns its keep

License-plate recognition pays for itself in a handful of well-worn jobs, and naming them keeps expectations grounded. The biggest is parking and access control: a gate opens for a resident's allowlisted plate without a fob, a ticketless lot bills by plate, a campus or depot lets approved vehicles in and logs the rest. The second is tolling and road charging — free-flow toll lanes, low-emission and congestion zones that bill or screen by plate at speed. The third is security and enforcement: alerting when a watchlisted vehicle appears, supporting an investigation, or flagging a stolen plate — the area where the movement-history concerns above are sharpest and the governance must be strongest. Around these sit a long tail of smaller uses: drive-through and curbside pickup that greet a known customer, dwell-time and traffic analytics, and fuel-forecourt or weighbridge automation.

In each, the accuracy-vs-performance discipline is the same: the read is high but not perfect, so the workflow must tolerate a misread gracefully — an allowlist miss falls back to an intercom, an enforcement hit is confirmed by a human looking at the plate image, not actioned blind. A plate read is a strong signal, not a verdict.

Where Fora Soft fits in

Fora Soft has built real-time video, streaming, and computer-vision software since 2005, across 625+ shipped projects, and license-plate recognition is a feature where we spend most of the effort before the camera ever sees a plate — on the lane geometry, the angle, the shutter and infrared, and the read point, because that is where capture rate is won or lost. We lead with how the system behaves under real load first: the separate capture and read rates measured on the client's own lane and plate mix, the graceful-fallback workflow for the inevitable misread, and the retention and access design that keeps the stored history lawful and minimal — and only then the capability. A plate system that is honest about its two accuracy numbers and built to delete on schedule beats one that demos a perfect read and quietly accumulates a liability.

What to read next

• Face recognition in surveillance: how it works and where it is restricted
• The video-analytics map: what a surveillance system can detect
• GDPR for video surveillance

Call to action

• Talk to a surveillance engineer — book a 30-minute scoping call to talk through your license plate recognition camera plan.
• See our case studies — 250+ shipped projects across video streaming, WebRTC, OTT, telemedicine, e-learning, surveillance, and AR/VR.
• Download the License-Plate Recognition (LPR / ANPR) — One-Page Reference — What LPR is (LPR=ANPR; LPC is capture-only; identifies a vehicle and its keeper, not the driver), the four-step pipeline (find, clean, OCR, validate/match), accuracy as capture rate × read rate (≈98% × ≈95% ≈ 93%, never 100%) and the….

References

1. ONVIF — "Profile M" (standardizes analytics metadata and events; defines metadata for geolocation, vehicle, license plate, human face and body, and event interfaces for object-counter, face- and license-plate-recognition analytics; events carried over the metadata stream, the ONVIF event service, or MQTT; example use case "access control in a parking lot through license-plate-recognition apps"; conformance is a baseline for interoperability, not a guarantee of accuracy — the standardized channel through which a plate event surfaces into the VMS). Primary (tier 1). https://www.onvif.org/profiles/profile-m/
2. European Union — "GDPR, Regulation (EU) 2016/679, Art. 4(1) (personal data) and Art. 6 (lawful basis)" (personal data is any information relating to an identifiable person, including an identification number; a plate processed in an identifying context is personal data and needs a lawful basis — the basis for 'a plate is personal data and GDPR applies'). Primary (tier 1). https://eur-lex.europa.eu/eli/reg/2016/679/oj
3. European Data Protection Board — "Guidelines 3/2019 on processing of personal data through video devices" (video processing of personal data needs a lawful basis and transparency; systematic monitoring of a publicly accessible area triggers a DPIA under GDPR Art. 35; the EDPB distinguishes plate/location data from special-category biometric data — the basis for the ANPR deployment duties and the 'personal data, not biometric' line). Primary / issuing-body guidance (tier 1). https://www.edpb.europa.eu/our-work-tools/our-documents/guidelines/guidelines-32019-processing-personal-data-through-video_en
4. California Legislature — "SB 34 (2015), Civil Code §1798.90.5 et seq. (Automated License-Plate Recognition systems)" (requires a usage-and-privacy policy, access logs, reasonable security, and — for public agencies — bars selling/sharing ALPR data except to other public agencies — the basis for the US state-safeguard example and the retention/sharing framing). Primary (tier 1). https://leginfo.legislature.ca.gov/faces/billNavClient.xhtml?bill_id=201520160SB34
5. UK Home Office / National Police Chiefs' Council — "National ANPR Service: Data Protection Impact Assessment" (the UK national ANPR capability records on the order of 60 million reads/day, retains data for 12 months, and restricts access via role-based controls — the basis for the UK scale-and-governance example). Primary / official (tier 1/2). https://www.gov.uk/government/publications/national-anpr-service-data-protection-impact-assessment/national-anpr-service-data-protection-impact-assessment-accessible
6. Information Commissioner's Office (UK) — "Automatic Number Plate Recognition (ANPR)" guidance (ANPR operators must complete a DPIA before deployment to show the use is necessary and proportionate, and comply with the Surveillance Camera Code of Practice under the Protection of Freedoms Act 2012 — the basis for the UK DPIA/oversight duties). Primary / issuing-body guidance (tier 1/2). https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/cctv-and-video-surveillance/guidance-on-video-surveillance-including-cctv/additional-considerations-for-technologies-other-than-cctv/automatic-number-plate-recognition-anpr/
7. Electronic Frontier Foundation — "Street-Level Surveillance: Automated License Plate Readers (ALPRs)" (ALPRs are a mass-collection technology; more than 99.9% of collected plate data is unconnected to any crime or investigation; reader data is often retained for years and held in private databases such as Flock Safety and Vigilant/Motorola — the basis for the movement-profile risk and the retention/sharing concern). Institutional / analyst (tier 5). https://sls.eff.org/technologies/automated-license-plate-readers-alprs
8. IPVM — "Camera configuration and shutter speed for LPR" discussions (dedicated LPR cameras use fast shutters to freeze plate motion, infrared illumination tuned to retroreflective plates for night reads, a tight controlled field of view, and global-shutter sensors for fast lanes; capture rate vs read rate as distinct system metrics — the basis for the dedicated-camera and two-metric framing). Institutional / analyst (tier 5). https://ipvm.com/discussions/shutter-speed-in-lpr-situations
9. Adaptive Recognition — "Carmen FreeFlow ANPR engine" and field guidance (free-flow ANPR engines read plates across speed and lighting variation; vendor read/capture figures are condition-dependent and quoted for controlled conditions — the basis for the controlled-vs-free-flow accuracy spread, used as a vendor field reference, not a standards source). Vendor engineering (tier 4). https://adaptiverecognition.com/products/carmen-freeflow/
10. Viso.ai — "Automatic Number-Plate Recognition (ANPR) Guide" (orientation on the detection → preparation → OCR → post-processing pipeline and the deep-learning detector + OCR approach; used for orientation, with all standards/legal claims sourced to the primary documents above). Educational (tier 6). https://viso.ai/computer-vision/automatic-number-plate-recognition-anpr/