How the California DMV vanity plate checker actually works

If you've tried to claim a California vanity plate, you already know the drill: the DMV's configurator makes you agree to the terms of use, type the plate character-by-character into a form, and then hit a “Check availability” button. Do this twenty times to find one plate that's not already taken.

This post explains what's actuallyhappening under that form, because once you know the three endpoints involved, you know why every third-party “plate checker” site on the first page of Google is doing exactly the same thing — just with a nicer UI and a paywall glued on.

The three endpoints

The whole availability flow lives under https://www.dmv.ca.gov/wasapp/ipp2/ and uses three URLs:

1. GET /initPers.do — renders the acknowledgment page and hands your browser a pair of AWS ALB cookies.
2. POST /startPers.do with body acknowledged=true&_acknowledged=on — tells the DMV you've read the terms. Response sets a JSESSIONID cookie. This is your session.
3. POST /checkPers.do — the actual availability check. Takes one plate's worth of form fields, returns a tiny JSON blob like {"success":true,"code":"AVAILABLE","message":"PLATE_AVAILABLE"}.

The response codes you'll see:

• AVAILABLE — the plate is open right now.
• NOT_AVAILABLE — already issued to someone else.
• VALIDATION — the plate violates DMV rules (reserved characters, profanity filter, too many consecutive identical characters, all-numeric, etc.).
• SESSION_TIMEOUT — your session went idle for ~15 minutes.

The reCAPTCHA red herring

The acknowledgment page includes a Google reCAPTCHA v3 widget, which is why a lot of people (including an earlier version of me) assumed you need a headful browser + real user gestures to check plates programmatically.

You don't. As jonlu documented, the reCAPTCHA token is generated but never actually validated server-side. A plain fetch() call with the terms-acknowledgment cookies gets the same JSON response a real browser would.

The plate rules

California plates, for the standard sequential issue and for the Environmental personalized plate (the white-background one most people mean by “vanity plate”):

• 2 to 7 characters. One-character plates are reserved.
• A–Z, 0–9, and a single space.No hyphens, no punctuation, no emoji. “Half-spaces” exist on paper but aren't exposed by the online configurator.
• Can't be all numeric. 12345 comes back as VALIDATION / invalid.characters.
• Can't duplicate an existing issued plate — that's the NOT_AVAILABLE response.
• Blocked content. DMV runs a profanity/objectionable-content filter. The exact list isn't public, but you can infer the shape of it from a few VALIDATION responses.

Why every “plate checker” site is the same thing

There is exactly one source of truth for CA plate availability, and it's the DMV's own checkPers.do endpoint. There's no public list of issued plates, no bulk-export API, no partner program. Any site that tells you a plate is available is either:

• Calling checkPers.do themselves (like this site does), or
• Embedding a browser iframe that drives the DMV configurator for you, or
• Lying — serving a cached guess and charging you anyway.

If a site claims “real-time availability” and asks for a subscription, it's option one with extra steps.

What to do with this information

If you just want a plate: use ClaimPlate. Describe a vibe, get 20 candidates, see which ones are green. It's free, there's no signup, and the green ones click through to the DMV's actual order page so you can pay the DMV, not me.

If you want to check one specific plate: type claimplate.com/plate/YOUR_PLATE directly in the address bar — the page will run the check and tell you the verdict.

If you want to write your own checker: start with the three endpoints above, reuse the JSESSIONID cookie across requests, add a 250ms delay between plates so you're not hammering the DMV, and handle the SESSION_TIMEOUT code by re-acking and retrying. The whole thing is less than 200 lines in any language that can do cookies and JSON.