How age checks work — and how well

Age assurance is not a setting a parent sets.

It is something that happens to a child.

A child opens an app, signs up to a game, joins a chat, or downloads an 18+ app.

Somewhere behind the form, the service decides whether the user in front of it is old enough.

The decision is made from one or more of four broad technical mechanisms.

A self-typed birthday, a government ID, a face image, or a payment instrument.

A fifth route joined the picture during 2025 and 2026: the operating system sharing a parent-set age signal with the app [source: apple-declared-age-range] [source: www-biometricupdate-declared-age].

This page is about those mechanisms.

It covers what each method technically does, what data the service sees, and what the user gets back.

The companion page What the evidence says about age verification covers the second half.

It covers how well each method actually places a child on the correct side of a boundary, and what the independent research does and does not support.

Definition

Age assurance is the umbrella term for any method a service uses to estimate or verify a user’s age.

Ofcom distinguishes the family of methods in three terms that the rest of this page relies on:

• Self-declaration — the user states their own age. The service has no independent check.

• Age estimation — the service infers an age range from a signal such as a face image, with no document presented [source: ofcom-age-assurance-2026].

• Age verification — the service confirms an exact age, typically against a government-issued document [source: ofcom-age-assurance-2026].

The legal context is set by GDPR Article 8.

It fixes the age of digital consent at 16 across the EEA by default.

It also lets each member state lower the age, “provided that such lower age is not below 13 years” [source: euconsent-gdpr-art8].

The European Commission’s 2026 blueprint adds a third pathway: privacy-preserving proof of age.

It is designed to let a user prove they are over a threshold without revealing the identity behind the proof [source: digitalstrategy-ec-age-verification-2026].

The terms assurance, verification and estimation are not interchangeable.

A vendor that says it “verifies age” is making a stronger claim than one that “estimates age”.

The test method the vendor has actually run is the difference [source: ofcom-age-assurance-2026].

Scope

This page covers the technical mechanism behind each method.

It covers what the user submits, what the service stores, and what the service returns.

It does not cover how accurate each method is at the boundary that matters for a child’s account.

That question is on the sister page What the evidence says about age verification.

It also does not cover the per-platform mechanics of an account birthday triggering a state transition.

That is on Accounts, age limits and what a birthday changes.

What this page is:

• A field guide to the five common methods in deployment in 2026.
• A description of the data each method needs to see in order to work.
• An honest account of what each method does not do.

What this page is not:

• A product comparison. Services are named only as examples. The list of providers is not the point.
• A guide for evading age checks. The methods are described so parents can read what is happening, not so a child can route around it.

Why this matters

The 2026 evidence from Ofcom — the UK communications regulator — is the clearest single picture of the change that is already under way.

Ofcom reports that the share of children in the UK encountering highly effective age checks rose from 25% to 43% between July 2025 and January 2026.

Across a sample of 32 UK services, more than 69 million age checks were completed between July and December 2025 — a 23-fold increase on the prior six months [source: ofcom-age-assurance-2026].

A parent’s mental model often still assumes self-declaration is how age is checked.

The UK regulatory position is that self-declaration alone does not count as effective age assurance [source: ofcom-age-assurance-2026].

The European Commission’s 2026 blueprint goes in the same direction.

It routes proof of age through an external, reusable mechanism rather than asking each service to reinvent its own [source: digitalstrategy-ec-age-verification-2026].

Three consequences follow for parents of children between 6 and 16:

1. The child is being asked for proof more often. ID upload, a face image, or a credit card are now realistic prompts during a routine sign-in. The child is unlikely to know that the default birthday is the lowest-stakes answer.

2. The OS is now in the loop. Apple’s Declared Age Range API propagates a parent-set age range from the Apple Account to third-party apps that ask [source: www-biometricupdate-declared-age]. Apple itself frames this as an alternative to biometric checks. The age the parent set on day one is now a piece of shared infrastructure, not a local setting. Setting it wrong propagates.

3. Facial age estimation is becoming default for the largest chat-based platforms. Roblox describes a global deployment in which chat is gated by a third-party facial estimate rather than the birthday the child typed [source: roblox-age-estimation]. The accuracy of that estimate at the legal boundary that decides the child’s chat group is the subject of the sister page, not this one.

The rest of this page walks through the methods, in roughly the order of how much data they see.

Self-declaration

A text field.

The user types a date or selects an age band.

The service stores it.

What the service sees. A typed string. A date of birth or a yes/no over a threshold. No document, no image, no payment instrument.

What the service stores. The birthdate itself. Often with the IP address and user-agent string captured at signup. And a derived “current age” that is recomputed at the next access.

What the user gets back. Usually a feature gate — full access, restricted access, or denial — and, depending on the platform, a subsequent age-band derivation.

Apple’s App Store rating tier and the Google Account child-account threshold are both derived from the typed date [source: apple-region-rules] [source: google-age-requirements].

Cost. Essentially zero data beyond a date. No biometric, no financial instrument, no identity document.

What it cannot do. A typed date has no relation to the person typing it.

Ofcom’s 2026 review is explicit that self-declaration is not treated as effective age assurance under the UK Online Safety regime [source: ofcom-age-assurance-2026].

A 12-year-old who can read can also type a different year.

This is the method that almost every service still uses for the signup step.

The trend documented by Ofcom is that an additional method is layered on top, not that self-declaration is removed.

ID-based verification

A document.

The user uploads, scans, or photographs a government-issued identity document.

Typically a passport, national ID card, or driving licence.

A verification vendor extracts the date of birth and returns an age signal to the relying service.

What the service sees. A document image plus the extracted fields.

Whether the image, the extracted data, or both are retained by the service, the verification vendor, or both is a question of contract and jurisdiction.

The UK Information Commissioner’s Office requires that data minimisation, purpose limitation, retention and security be made explicit in any Data Protection Impact Assessment for high-risk processing [source: ico-biometric-age-assurance].

What the user gets back. A verified age, typically rounded to a whole number and compared to the gate. Roblox describes ID verification as the principal correction route for eligible users whose facial estimate placed them in the wrong bracket [claim: roblox-age-checks-2026].

Cost. The most data of any method. A government identity document, in the hands of a private vendor, in a database the parent does not see.

The UK ICO’s analysis of biometric data treats the boundary between “ordinary” and “special category” processing as purpose-dependent, not as automatic from the presence of a face [source: ico-biometric-age-assurance].

The same logic does not transfer to identity documents themselves.

The document is already identifying, regardless of biometric special-category status.

What it cannot do. An ID proves the document, not the person in front of the camera.

Document-only checks answer whether the typed date of birth matches an issued document.

They do not, on their own, prove the person submitting the document is the person the document was issued to.

A liveness step is sometimes layered on top. Whether that liveness is robust is a separate question not answered in the public evidence this wiki retrieved.

This is the strongest method the service itself can deploy.

It is also the method the user is most likely to refuse.

Facial age estimation

A face image.

The user looks at a camera, typically for a few seconds.

A model returns an age estimate, usually with a confidence score and sometimes a “liveness” verdict.

What the service sees. A face image, or — depending on the implementation — a face embedding derived from it, or only an age band derived from both.

The data flow is opaque.

The vendor’s own data-retention policy and the data-protection regime in the user’s country are the two relevant constraints [source: ico-biometric-age-assurance].

What the user gets back. An age band or a yes/no over the service’s gate.

Roblox describes a six-band system — under 9, 9–12, 13–15, 16–17, 18–20, 21+ [source: roblox-age-estimation] [claim: roblox-age-estimation].

Chat is limited to the user’s own and adjacent bands.

Other vendors use different banding. Some return only a binary result.

Cost. A face, even briefly.

The data-protection status of that face is not automatic.

The UK ICO’s analysis is explicit that biometric data are not automatically “special category” under UK GDPR merely because a face is processed.

The test is whether the data are processed for the purpose of unique identification [source: ico-biometric-age-assurance].

A face used only to produce an age band, with the image then discarded, is not uniquely identifying in the same way.

That analytical claim is contested. The regulatory position in the EU is still being developed [source: digitalstrategy-ec-age-verification-2026].

What it cannot do. The accuracy of the estimate at the boundary that decides the user’s rights is the question the evidence base is most contested on.

The Australian Age Assurance Technology Trial is the most direct independent test of age estimation at the 13+ and 16+ gates the wiki has located.

In its pooled sample, the trial reports a false-positive rate of 62.89% for true 12-year-olds against a 13+ gate (n = 1,315).

It reports a false-negative rate of 23.57% for true 13-year-olds (n = 1,485).

Against a 16+ gate, a true 15-year-old was admitted 73.26% of the time (n = 374).

A true 16-year-old was rejected 13.90% of the time (n = 770) [source: ageassurance-aatt-age-estimation-2025].

Those values are not transferable to any one commercial system.

The trial’s own best-system mean absolute error is around 1.3 to 1.5 years [source: ageassurance-aatt-age-estimation-2025].

That population summary hides much larger error probabilities immediately around the rights boundary.

The sister page covers this in detail.

This is the method that scales cheapest per user, and the method with the most contested evidence base at the boundary.

Payment-based inference

A financial instrument.

The user presents a credit card, a debit card, or sometimes a bank-issued age-verification token.

The service either charges a small amount and refunds it, or reads the cardholder’s age where the card network exposes it.

What the service sees. A card number, an expiry, sometimes a billing address.

The cardholder’s age is not typically part of the card data.

Most networks do not transmit the cardholder’s date of birth to the merchant.

What the payment step typically proves is that the user is the holder of a live payment instrument, not that they are over a specific age.

What the user gets back. A confirmation that a payment method exists.

The age inference is a side effect: a cardholder must be 18+ in most card-network terms-of-service to hold a primary credit card.

A payment check therefore often functions as a proxy for “is at least roughly adult”, not as a precise age estimate.

Cost. A live financial instrument is exposed to the verification vendor.

Card data are subject to PCI-DSS and to the merchant’s data-handling practices.

The verification mechanism is also implicitly biased.

Children whose family does not let them hold a card cannot pass it.

Children with a parent’s card borrowed for a signup can.

What it cannot do. It cannot, in most implementations, distinguish a 13-year-old from a 17-year-old or a 21-year-old.

The signal is coarser than the gate.

It is a useful fallback when the service wants to keep out users without any payment capacity.

It is not a method for placing a child on the correct side of a 13 or 16 boundary.

Account-mediated signals

The operating system, not the service, decides.

The mechanism is the Apple Declared Age Range API.

The parent sets an age range on the child’s Apple Account.

When a third-party app asks the OS for the user’s age range, the OS returns the parent-set signal [source: apple-declared-age-range].

The same architecture is documented for the App Store, where a child gaining access to a tier is derived from the Apple Account birthdate [source: apple-appstore-age-ratings].

What the app sees. A boolean over a threshold, or an age range.

It does not see the birthdate.

It does not see the name, the Apple ID, or any identifier that would let it correlate the age check across services.

What the OS sees. The birthdate the parent set, plus the list of apps that have asked.

The OS is the trust broker.

The trade-off, made explicit in Apple’s framing, is that the user trusts the device vendor more than the app vendor [source: www-biometricupdate-declared-age].

What the user gets back. A consistent age signal across apps that opt in.

Apple’s rollout to US states began with Utah on 2026-05-06 and Louisiana on 2026-07-01 [source: www-biometricupdate-declared-age] [source: apple-dev-age-requirements].

In Australia, Brazil and Singapore, an adult confirmation gate for 18+ app downloads was required from 2026-02-24.

Cost. A second party — the OS vendor — sits between the parent and the app.

The parent cannot see which apps have asked, except through the OS vendor’s own transparency mechanisms.

What it cannot do. It cannot propagate back.

An app that independently learns the user is older — through a payment flow, for example — cannot update the OS record.

The signal is one-way [source: apple-declared-age-range].

It also cannot protect a child who uses another account on another device.

The signal travels with the Apple Account, not with the person.

Privacy-preserving proof of age

A reusable proof, separate from any one service.

The European Commission’s age-verification blueprint was first released on 2025-07-14.

It reached a feature-ready version on 2026-04-15.

It is a privacy-preserving architecture.

A user proves to a relying service that they are over an age threshold.

The user does not disclose the underlying identity or other attributes to the relying service [source: digitalstrategy-ec-age-verification-2026].

What the relying service sees. A proof that the user is over the threshold, signed by an issuer it trusts. Nothing else.

What the issuer sees. The user’s identity proof — the document or biometric — at the moment of issue.

The issuer does not see the relying service.

The relying service does not see the document.

What the user gets back. A reusable proof.

Different services that trust the same issuer can re-verify without re-collecting the underlying document.

Cost. Architectural.

The cost is a new trust broker — the issuer — between user and relying service.

The privacy win is that the broker is not the relying service.

What it cannot do, in 2026. The blueprint is not yet a production system with named, live issuers that every relying service in the EU trusts.

UK Ofcom’s review notes that some services already use a layered approach, but heterogeneous fallback and appeal design means the user experience is uneven [source: ofcom-age-assurance-2026].

A privacy-preserving architecture, on paper, solves the data-minimisation problem that the other methods leave open.

In deployment, it depends on which issuers and which relying services have agreed to use it.

What the methods share

A few things are true of every method above, regardless of how the data are collected.

The method is only the input. The age band, the binary result, and the challenge age are choices the service makes on top of the method.

Ofcom’s review of UK services found that facial-estimation providers most often set a challenge age of 21 — above the legal boundary of 18 — to manage false-accept risk [source: ofcom-age-assurance-2026].

The choice of where to draw the line is a policy decision, not a property of the algorithm.

The fallback shapes the user experience. Ofcom’s review also found that appeal and review designs across services are heterogeneous.

Some services offered manual review or alternative methods.

Some offered only another attempt using the same method.

Some offered no appeal at all.

Only six of the examined services supplied data on upheld appeals [source: ofcom-age-assurance-2026].

The same vendor accuracy figure produces very different experiences depending on what happens after a refusal.

The error costs are asymmetric. A false positive admits an underage user to a tier they should not occupy.

A false negative denies an eligible user.

Ofcom’s evidence shows that the most common practice is to err on the side of false negatives and push the user into a more onerous re-check [source: ofcom-age-assurance-2026].

That trade-off is a policy choice, not a property of any method.

The data the method sees is the data the user has to give. A child cannot meaningfully consent to a face image or an ID upload.

The consent question is the parent’s.

eSafety’s guidance on the Australian Social Media Minimum Age regime makes this point directly.

The parent is the relevant party for biometric and identity-bearing checks on a minor’s account [source: esafety-smma-guidance-2025].

What a parent can practically do

Age assurance is not a configuration the parent toggles.

The practical questions a parent can answer are nonetheless concrete.

• Read the age gate before the child signs up. The prompt to upload an ID, scan a face, or hand over a credit card is the visible signal. The “what does this method see” decision is the parent’s, made on the child’s behalf.

• Treat the typed birthday as a permanent record. A wrong birthdate typed on day one propagates to every age-gated app later. Apple’s Declared Age Range API carries the OS age to third-party apps [source: apple-declared-age-range]. Google’s child-account threshold is derived from the typed date [source: google-age-requirements].

• Ask which method the service uses, and what it stores. Services that publish a method, a retention period, and an appeal path are the services whose age check is auditable. Services that do not publish those things are the ones where the method is the vendor’s, and the parent has no way to verify the claim.

• Plan for the false-negative case. Ofcom’s evidence on UK services shows that a non-trivial share of age checks fail and require retries or alternative methods [source: ofcom-age-assurance-2026]. If the child has been re-binned into the wrong bracket, the correction path needs to be a known path, not a discovery at the moment of exclusion.

• Do not read a single “X% accuracy” figure as a verdict on the child’s case. The number the vendor publishes is a population summary. The evidence page covers why population summaries can hide large boundary errors.

What this page does not do

It does not tell you which method to prefer.

The independent evidence does not yet support a single ranking of methods [source: ageassurance-aatt-age-estimation-2025] [source: ofcom-age-assurance-2026].

The user’s situation is the deciding factor, not a universal ranking.

The country, the platform, the data the user is willing to expose, and the appeal design on offer are the relevant inputs.

It also does not tell you which method the service you are about to use actually uses.

Where the service publishes the method, the parent can read it.

Where the service does not publish it, the parent is being asked to trust the service.

The minimum to ask for is a published method and an appeal path.

Sources

• euconsent-gdpr-art8 — GDPR Article 8, the default age of digital consent at 16 with member-state reductions to no less than 13 [source: euconsent-gdpr-art8].
• ofcom-age-assurance-2026 — Ofcom, Use of Age Assurance Report 2026. The 25%-to-43% rise in highly effective age checks, the 69-million-checks figure across 32 UK services between July and December 2025, the position that self-declaration is not effective, and the challenge-age and appeal evidence [source: ofcom-age-assurance-2026].
• ofcom-age-checks — Ofcom, Age checks to protect children online. The parent-facing explainer for the same regime [source: ofcom-age-checks].
• apple-declared-age-range — Apple Developer, Declared Age Range. The mechanism by which the OS shares a parent-set age range with apps, and the one-way direction of the signal [source: apple-declared-age-range].
• apple-age-assurance-qa — Apple Developer, Age assurance frameworks Q&A. Apple’s framing of the framework evolution across iOS 26 [source: apple-age-assurance-qa].
• apple-appstore-age-ratings — Apple Developer, App Store age ratings values and definitions. The five-tier rating system (4+, 9+, 13+, 16+, 18+) [source: apple-appstore-age-ratings].
• apple-dev-age-requirements — Apple Developer News, Age requirements for apps in Brazil, Australia, Singapore, Utah, Louisiana. The state-level enforcement dates [source: apple-dev-age-requirements].
• apple-region-rules — Apple Support, Region-specific rules for managing an Apple Account. The country-by-country child-account thresholds [source: apple-region-rules].
• google-age-requirements — Google Account Help, Age requirements on Google Accounts. The country-by-country minimum-age table [source: google-age-requirements].
• ico-biometric-age-assurance — ICO, Expectations for age assurance and data protection compliance. The DPIA requirement, the biometric-purpose analysis, and the data-minimisation framing [source: ico-biometric-age-assurance].
• ico-equality-impact-2025 — ICO, equality-impact material addressing the demographic evidence gap in facial age estimation [source: ico-equality-impact-2025].
• digitalstrategy-ec-age-verification-2026 — European Commission, EU age verification. The privacy-preserving blueprint, first version 2025-07-14, feature-ready 2026-04-15 [source: digitalstrategy-ec-age-verification-2026].
• esafety-codes-guidance-2026 — eSafety Commissioner, Online Safety Codes and Standards Regulatory Guidance. The recognition that age assurance is not 100% effective and the policy framing around biometric processing on a minor’s account [source: esafety-codes-guidance-2026].
• esafety-smma-guidance-2025 — eSafety Commissioner, Social Media Minimum Age Regulatory Guidance. The parent-as-consenting-party framing for biometric and identity-bearing checks [source: esafety-smma-guidance-2025].
• esafety-log132-2025 — eSafety Commissioner, document set LOG 132, including discussion of age-estimation error near the 16 boundary [source: esafety-log132-2025].
• ageassurance-aatt-age-estimation-2025 — Australian Age Assurance Technology Trial, Part D - Age Estimation. The pooled 13+ and 16+ threshold evidence cited above, the 1.3-to-1.5-year best-system MAE range, the provider-pooling rules, and the report’s own table-versus-prose contradictions [source: ageassurance-aatt-age-estimation-2025].
• nist-fate-aev-2026 — NIST, Face Analysis Technology Evaluation: Age Estimation and Verification, rolling report. The largest independent cross-vendor benchmark this wiki has located, with 49 algorithm submissions from 28 organisations current to 2026-07-31 [source: nist-fate-aev-2026].
• roblox-age-estimation — Roblox, Facial Age Estimation for Safer Chat [claim: roblox-age-estimation]. The vendor’s own description of the global deployment and the six age brackets.
• roblox-age-checks-2026 — Roblox Help, Understanding Age Checks on Roblox [claim: roblox-age-checks-2026]. The vendor’s documentation of the correction routes.
• roblox-estimate-age-2026 — Roblox Help, How does Roblox estimate my age? [claim: roblox-estimate-age-2026]. The vendor’s description of the estimation flow.
• www-biometricupdate-declared-age — BiometricUpdate, Apple updates Declared Age Range API for age assurance laws. Secondary reporting on the rollout schedule [source: www-biometricupdate-declared-age].