ANPR Software: How to Build License Plate Recognition

Why Fora Soft wrote this guide

We build computer-vision products for a living. Since 2005 we’ve shipped 250+ projects, and a good number of them are the exact pieces an ANPR system is made of: camera capture, object detection, tracking, OCR, and wiring the result into someone’s access-control or parking backend. When a client asks us to read license plates at a gate, a toll point, or a car-wash entrance, we’re not starting from a blank page — we’re deciding which engine to license and what to build around it.

We wrote this because most of what ranks for “anpr software” is either a vendor product page or a dictionary-style definition. There’s little that treats ANPR as an engineering decision: how the pipeline actually works, where accuracy really breaks, whether to use a cloud API or an on-prem SDK or open source, and what the whole thing costs over three years. That’s the gap here. Our video surveillance team and our AI group both weighed in.

One project shaped a lot of the thinking here: an object-recognition camera solution we built where the real work wasn’t the model — it was capturing usable frames in bad light and turning detections into something the client’s system could act on. Plate recognition has the same shape, and we’ll come back to it as a mini-case.

What ANPR software actually is

ANPR software is the code that turns an image of a vehicle into the machine-readable text of its number plate, then hands that text to another system to act on. Point a camera at a lane, and the software finds the plate in the frame, reads the characters, and outputs a string like 7XKR942 plus a timestamp and, often, the make and color of the car. Everything a business cares about — open the gate, start the parking clock, charge the toll, flag a watchlist hit — happens after that string exists.

The three acronyms trip people up, so let’s clear them first. ANPR (Automatic Number Plate Recognition) is the British and European name. ALPR (Automatic License Plate Recognition) and LPR (License Plate Recognition) are the US names. They describe the same technology; the term traces back to the UK Police Scientific Development Branch in 1976, per Wikipedia’s ANPR entry. If a spec says ALPR and a camera datasheet says ANPR, they’re talking to each other.

Here’s the mental model that matters for building: ANPR software is a reader, not a whole product. The reader is largely a solved problem you can license. Your product is the layer around it — the camera that feeds it clean frames, the database it checks plates against, the rules that decide what to do, and the audit trail that keeps you out of trouble. Get that straight and the rest of this guide falls into place.

How ANPR works: from frame to characters

An ANPR read is a short pipeline, and knowing the stages tells you where accuracy is won or lost. A frame comes in from the camera; the software first localizes the plate — draws a box around it in the full image — then normalizes it, straightening the perspective so a plate shot at an angle reads like a flat one. From there it does character recognition (OCR) to pull out the alphanumeric string, and finally post-processing and matching: applying country plate formats to fix likely errors, then checking the result against a database or rule.

Figure 1. The ANPR pipeline. Detection and OCR are the recognizer you license; capture on the left and matching on the right are what you build and tune.

Older systems split detection and OCR into hand-tuned steps with explicit character segmentation. Modern engines use deep learning end to end: a YOLO-family object detector finds the plate directly in the frame, and a CRNN or transformer OCR reads the crop without segmenting characters one by one. Systems built this way report over 97% on standard US and EU plates, with detection running in roughly 100 ms a frame (weboccult ANPR guide, 2025). If you want the detector side in depth, our object-recognition machine-learning write-up covers how those detection models are trained and tuned.

The takeaway from Figure 1: the two middle boxes — detect and read — are the part you almost never write from scratch. Licensed engines do them well across dozens of countries. Your engineering time goes into the first box (getting a clean, well-exposed plate into the frame) and the last box (matching, deduplication, and deciding what a read means). That’s where a project succeeds or stalls.

What ANPR accuracy really means

Vendors love to say “99% accurate.” The honest number is a range: modern ANPR reaches 99%+ in controlled lanes and 90–98% in real-world conditions, according to Carmen Cloud’s accuracy analysis (Carmen Cloud, 2026). The spread between those numbers is entirely about conditions, and conditions are mostly about how you place and configure the camera — not which model you bought.

Figure 2. Illustrative accuracy by capture condition. The recognizer is the same in every bar; what moves the number is light, angle, speed, and plate condition.

Five things move the number, and every one is a design choice. Light: headlights and low sun blow out a plate; the fix is an infrared-illuminated camera so a plate reads the same at midnight as at noon. Angle: a plate shot from too far to the side is hard to de-skew — keep the camera within a modest horizontal and vertical angle of the plate. Speed: a highway lane needs a fast shutter to freeze the plate, which is a different camera from a 5 mph parking gate. Plate condition: mud, damage, tinted covers, and non-standard fonts all cost reads. Placement and calibration: mounting height and distance decide how many pixels land on the plate, and pixels are accuracy.

The practical lesson we repeat on every project: buy accuracy at the lens, not just in the software. A purpose-built ANPR camera aimed at one lane — a proper LPR camera system — will beat a better recognizer fed by a general-purpose camera pointed at three. This is the same principle we cover for detection generally in our AI-powered IP camera guide — the capture layer sets the ceiling for everything downstream.

Where ANPR earns its keep

ANPR pays off anywhere a plate is a cheaper, faster identifier than a card, ticket, or human. The plate is already on the car, so the vehicle becomes its own credential. The common deployments split into a few buyer segments, and the segment decides how much accuracy and speed you actually need.

Parking and access control. Ticketless parking, gated communities, and corporate lots read the plate on approach and open the barrier for known vehicles or start a payment session for visitors. Conditions are gentle — slow speed, fixed angle, often covered lighting — so accuracy is high and the build is mostly integration with the barrier and payment systems.

Tolling and traffic. Highway toll and congestion-charging systems read plates at speed, in all weather, and reconcile them against accounts. This is the demanding end: fast shutters, multiple cameras per lane, and tight accuracy targets because every miss is a manual review or a lost charge.

Commercial and enforcement. Car washes and drive-throughs tie a plate to a loyalty account for faster service; fleets track vehicles in and out of depots; law enforcement matches plates against hotlists. The enforcement cases raise the privacy stakes sharply, which we get to below.

Edge, cloud, or hybrid: where recognition runs

One architectural decision shapes cost, latency, and privacy more than any other: where the recognition actually happens. There are three patterns, and they map cleanly onto the deployment choices we cover in our edge AI surveillance architecture guide.

Figure 3. Three places recognition can run. Edge keeps images local and cheap to run; cloud is simplest to start; hybrid sends only the read, not the image.

Edge runs the recognizer on the camera or a small box beside it — a Jetson, a mini-PC, or an LPR camera with the engine built in. Plates are read on site, so raw images never leave the property, latency is milliseconds, and there’s no per-lookup cloud bill. The cost is managing hardware in the field. Cloud ships each image to a hosted API that returns the plate. It’s the fastest way to start and the easiest to scale, but you pay per lookup and you’re sending vehicle images off site, which matters for privacy and bandwidth.

Hybrid is where most serious deployments land: read the plate at the edge, then send only the resulting text and metadata to the cloud for matching, dashboards, and multi-site aggregation. You get local privacy and low latency plus central management, and your cloud bill is tiny because you’re moving strings, not video. When a client cares about both data control and a single pane of glass across sites, hybrid is almost always the answer.

Your software options: cloud API, on-prem SDK, open source

Once you know where recognition runs, you pick how you get the recognizer. There are four routes, from least to most engineering.

1. Cloud API. Send an image, get back a plate. Engines like Plate Recognizer or Carmen Cloud handle multi-country reads and updates for you. Fastest to ship, usage-priced, no hardware — but images leave your network and cost scales with volume.

2. On-prem SDK. The same engine as a library you run on your own machine — server, Jetson, or Raspberry Pi. Plate Recognizer’s SDK, for instance, runs offline and only checks its license periodically. You get privacy and no per-lookup fee at the price of running the box yourself.

3. Open source. Assemble your own from a YOLO detector and an OCR model, or use a framework like FastALPR. No license fee and full control, but you own accuracy, country coverage, and maintenance forever. More on this two sections down.

4. VMS-integrated. A video management system such as Genetec AutoVu ships ANPR as a module. If you already run that VMS, this is the path of least resistance; if you don’t, it’s a big commitment for one feature.

ANPR engines compared

Here’s how the common engines line up. Prices and terms are from each vendor’s own pages, captured July 15, 2026 — verify before you quote, because ANPR pricing shifts and most enterprise tiers are custom.

The pattern: a licensed engine (Plate Recognizer, Carmen, Rekor) reads plates well today, and picking one is mostly about deployment fit and country coverage. Open source is free to license and expensive to own. A custom build is not about the recognizer at all — it’s about the product you wrap around one. The next three sections make that call explicit.

Can you just use open source?

Sometimes — but know what you’re signing up for. The famous name, OpenALPR, is a cautionary tale: the original open-source library was acquired by Rekor Systems in 2019 and folded into a commercial product, and the public repo is effectively frozen. Building on it today means building on abandoned code.

The live options are newer. FastALPR ships fast ONNX models — open-image-models for detection, fast-plate-ocr for reading — and there are current YOLO11 and YOLOv8 plus CRNN projects that read plates well on the datasets they were trained on. If you have a computer-vision team and a narrow, stable use case (one country, controlled lighting), rolling your own from these is viable and free of license fees.

The catch is ownership. A licensed engine gives you accuracy across 90+ countries, handles new plate designs, and comes with support; with open source, all of that is your job forever — retraining for new regions, chasing edge-case misreads, and patching the stack. For most commercial deployments the license fee is far cheaper than a standing ML maintenance burden. Open source wins when control and zero licensing genuinely outweigh that ongoing cost.

Build vs buy: when licensing an engine stops fitting

For most teams, license the recognizer and build the product around it. You should almost never write the OCR engine yourself — that’s solved, and solved better than a from-scratch effort will manage in a reasonable budget. So “build vs buy” for ANPR isn’t really about the reader. It’s about how much of the surrounding system is yours.

Three forces push toward a custom build. Data control: plate and vehicle data can’t leave your infrastructure — a common demand in government, security, and privacy-sensitive deployments — so a cloud API is out and you build on an on-prem SDK or your own models. Differentiation: ANPR is part of your product, not an internal tool — a parking platform, a security product, a fleet SaaS — and the workflow around reads is your moat. Fit: your rules, matching logic, or integrations are unusual enough that no off-the-shelf ANPR app models them.

The middle path we recommend most often: license a strong engine (cloud or on-prem SDK) and build the capture tuning, matching, rules, dashboards, and integrations on top. You get proven recognition accuracy immediately and spend your engineering budget where it differentiates you — which is never the OCR.

What an ANPR system actually costs

Let’s put conservative numbers on it. Three cost lanes matter, and they diverge fast with volume. A cloud API is usage-priced: Plate Recognizer’s 50,000-lookup plan is about $50/month (vendor page, July 2026), and one gate reading roughly one car a minute for twelve hours a day is around 21,600 reads a month — comfortably inside that tier. An on-prem SDK is licensed per camera or per box with no per-lookup fee, so it flattens as volume grows. A custom build adds one-time engineering and then runs cheap on an edge box plus storage.

Figure 4. Illustrative three-year cost by lane. Cloud is cheapest to start and rises with volume; on-prem and custom cost more up front and flatten. Where the lines cross depends on your lane count.

The honest read: at a handful of lanes and modest volume, a cloud or on-prem licensed engine is the right answer and it isn’t close — you’re paying tens to low hundreds of dollars a month plus a bit of integration work. The case for a heavier custom build isn’t “it’s cheaper.” It’s data control, differentiation, or a fit no product offers. We use an efficient, senior-led delivery model, so when a build is warranted we keep the one-time cost lower than a typical agency — but we’ll still tell you to license an engine when that’s the smarter spend. These figures are illustrative, not a quote; your real number depends on lane count, accuracy target, and integrations.

The privacy layer you cannot skip

A license plate linked to a person is personal data, and ANPR that logs where a car was and when can build a movement history. That makes privacy a design requirement, not a footnote. Treat what follows as design input, not legal advice — we’re engineers, not your counsel — but skip it and you ship a liability.

In the US, it’s a patchwork. There’s no federal ANPR statute; rules vary by state. A 2024 review by the National Conference of State Legislatures found that of 18 states studied, 16 set some limit on how long ALPR data can be retained, and state legislatures keep adding rules — Virginia’s statewide ALPR regulation took effect July 1, 2025. If you sell across states, retention has to be configurable per jurisdiction, not hard-coded.

In the EU and UK, GDPR applies. Plate data tied to an identifiable person needs a lawful basis, a defined retention window, and usually a data-protection impact assessment before you deploy. The engineering consequences are the same everywhere: capture consent or notice where required, cap retention and delete on schedule (including backups), lock down who can query the data, and log every access. Our video surveillance learning track covers the privacy-by-design patterns in depth.

The scale of the stakes is easy to underestimate: in 2026 the FBI began pursuing a contract worth up to $36 million for access to a nationwide, multi-vendor ALPR data network. Whatever your use case, design as if the data you collect is sensitive — because a plate history is.

Mini-case: our object-recognition camera build

On an object-recognition camera solution we built, the client assumed the model was the project. It wasn’t. The detector was the easy 20%; the other 80% was getting usable frames from real cameras in uneven light and turning raw detections into events the client’s system could act on without drowning operators in noise.

Two lessons carry straight into ANPR. First, capture is the ceiling. We spent real effort on camera placement, exposure, and framing, because a clean frame made the recognition look easy and a bad one made the best model look broken — exactly the accuracy story in Figure 2. Second, the value is in the layer after recognition: deduplicating repeat reads, matching against the right list, and firing the right action. That’s where a plate read becomes an opened gate or a flagged vehicle.

The transfer isn’t one-to-one — ANPR adds plate-format post-processing and the privacy layer above — but the shape is the same, which is why we can move quickly on a plate-recognition build instead of relearning the hard parts. Want a similar assessment for your use case? Grab 30 minutes and we’ll scope it.

A decision framework in five questions

Five questions get most teams to the right ANPR path without a month of deliberation.

1. Can vehicle images leave your network? If yes, a cloud API is the fastest start. If no — government, security, strict privacy — you’re on an on-prem SDK or your own models from the outset.

2. How hard are your conditions? Slow gates in good light are gentle; highway speed, night, and steep angles are demanding and push you toward purpose-built LPR cameras and higher accuracy targets.

3. What’s your volume, and how does it grow? Low and flat favors per-lookup cloud pricing. High or fast-growing favors per-camera on-prem licensing, where cost doesn’t scale with every read.

4. Is ANPR your product or an internal tool? Part of the product pushes toward building the surrounding system; an internal utility pushes toward buying an app or licensing an engine and moving on.

5. Do you retain the reads? If yes, the privacy layer — configurable retention, access control, audit logs — is mandatory, and it shapes your architecture. If reads are transient (open a gate, forget the plate), you’ve simplified the whole project.

Five pitfalls that wreck ANPR projects

1. Blaming the software for a camera problem. Most “the ANPR is inaccurate” complaints are exposure, angle, or too few pixels on the plate. Switching engines won’t fix a badly aimed camera; fix the capture first.

2. Ignoring night and weather. A system demoed at noon in a parking lot falls apart at 2 a.m. in the rain. Specify infrared illumination and test in the worst conditions the site will actually see, not the best.

3. Underestimating matching and deduplication. The same car sits in frame for seconds and generates many reads. Without deduplication and sensible matching rules, your “plate detected” feed is unusable noise. This logic is real work, and it’s yours.

4. Treating privacy as a later phase. Retention limits, access control, and audit logging are architecture, not polish. Bolting them on after launch — especially across US states or under GDPR — is expensive and risky.

5. Building the recognizer from scratch to save a license fee. Unless you have an ML team and a narrow use case, hand-rolling OCR to dodge a modest license is a false economy that ends with you maintaining a model instead of shipping your product.

KPIs: what to measure

Accuracy KPIs. Track read rate (share of vehicles that produce a plate at all) and character accuracy (share of reads that are exactly right), broken out by time of day and lane. A read rate that sags at night tells you the illumination is wrong; a character error clustered on one plate type tells you the region model needs work. Measure both, not a single vendor headline number.

Operational KPIs. Latency from capture to action (did the gate open before the driver got annoyed?), false-match rate (wrong car matched to a record), and duplicate-read rate. These decide whether the system feels instant and trustworthy or flaky, and they’re the numbers operators actually feel.

Business KPIs. The reason the system exists: manual interventions removed, throughput per lane, revenue captured (tolls, parking), or incidents caught. If ANPR isn’t reducing human work or capturing money the old process leaked, it isn’t earning its cost — and that’s the number that justifies the next lane.

When you don’t need ANPR (or shouldn’t build)

If your conditions are gentle and your volume is small, don’t build — license a cloud API or buy an off-the-shelf parking or access app and spend the engineering budget on your actual product. Writing your own recognizer to save a small monthly fee is the classic false economy in this space.

Sometimes ANPR is the wrong tool entirely. If you only need to know whether an authorized vehicle is present and you control the fleet, an RFID tag or a windshield transponder is cheaper and more reliable than reading a plate — no camera, no lighting problem, no privacy surface. ANPR earns its place when you can’t tag every vehicle in advance, which is exactly the open-population case: public parking, tolling, enforcement, visitor access.

The point of this section is trust: we’d rather point you to a $50/month API or an RFID tag than sell you a build you’ll regret. When a custom ANPR platform is genuinely right, the reasons are data control, differentiation, and fit — not cost.

FAQ

What is ANPR software?

ANPR software turns a camera image of a vehicle into the machine-readable text of its license plate, then passes that text to another system to act on — open a gate, start a parking session, charge a toll, or flag a watchlist hit. It runs a short pipeline: detect the plate in the frame, straighten it, read the characters with OCR, and match the result against a database or rule.

Is ANPR the same as ALPR and LPR?

Yes. ANPR (Automatic Number Plate Recognition) is the British and European term; ALPR (Automatic License Plate Recognition) and LPR (License Plate Recognition) are the US terms. They all name the same technology and are used interchangeably across datasheets and specs.

How accurate is ANPR software?

Modern ANPR reaches 99%+ in controlled lanes and 90–98% in real-world conditions (Carmen Cloud, 2026). The variance is almost entirely about capture conditions — lighting, plate angle, vehicle speed, and plate condition — not the recognizer. Good camera placement and infrared illumination matter more than switching engines.

How much does ANPR software cost?

A cloud API is usage-priced — Plate Recognizer’s 50,000-lookup plan is about $50/month (vendor page, July 2026) — while on-prem SDKs are licensed per camera with no per-lookup fee. A custom build adds one-time engineering plus low run cost on an edge box. For a few lanes at modest volume, licensing an engine costs tens to low hundreds of dollars a month; building only pays off with data-control, differentiation, or fit reasons.

Is there free or open-source ANPR software?

Yes, but with trade-offs. OpenALPR, the best-known name, was acquired by Rekor in 2019 and its open-source repo is effectively frozen. Live options include FastALPR (ONNX detection + OCR models) and current YOLO11/YOLOv8 plus CRNN projects. They’re free of license fees but you own accuracy, country coverage, and maintenance — viable if you have an ML team and a narrow use case.

Do I need special cameras for ANPR?

For anything beyond gentle, slow, well-lit lanes, yes. Purpose-built LPR cameras add infrared illumination for night reads and fast shutters for moving vehicles, and they’re aimed at a single lane so enough pixels land on the plate. A general-purpose camera can work at a slow parking gate, but capture quality sets the accuracy ceiling for the whole system.

Can ANPR read plates at night and at highway speed?

Yes, with the right camera. Infrared illumination handles darkness by lighting the plate’s reflective surface, and a fast shutter freezes plates at speed. These are camera and configuration choices, not software ones — the same engine reads a night highway plate and a daytime parking plate if the capture is right for each.

Is using ANPR/ALPR legal?

It’s regulated, not banned, and the rules depend on where you operate. In the EU and UK, plate data tied to a person is personal data under GDPR and needs a lawful basis and retention limits. In the US there’s no federal statute but a state patchwork — a 2024 NCSL review found 16 of 18 studied states cap ALPR data retention. Build configurable retention, access control, and audit logs, and involve counsel. This is design input, not legal advice.

What to read next

Ready to build your ANPR system?

The short version: ANPR software is a reader you almost always license, not a product you write from scratch. The recognizer detects the plate and runs OCR; your engineering goes into the capture that feeds it, the matching and rules that act on reads, and the privacy layer that keeps you compliant. Accuracy lives at the lens as much as in the model, so a purpose-built LPR camera aimed at one lane beats a better engine fed a bad frame.

For most teams, a cloud API or on-prem SDK at tens to low hundreds of dollars a month is the right call, and we’ll say so. Build custom when your data must stay in-house, when ANPR is part of your product, or when your workflow is the differentiator. If any of that fits, we’ve shipped the vision pieces before and can move fast.