Google Play privacy policy requirements: the 2026 checklist

Most developers meet this rule at the worst possible moment. The app works, closed testing is done, the store listing is half filled in, and Play Console stops you at a field that asks for a URL you don't have yet.

I run onTest, where developers get the 12 testers Google asks for before production. The question I hear most right after closed testing is some version of "what do I put in the privacy policy field?" This guide answers it with Google's own wording, so you can check your page against the actual rules instead of a vendor's summary of them.

Does every Google Play app need a privacy policy?

Yes. Google's User Data policy is direct about it:

All apps must post a privacy policy link in the designated field within Play Console, and a privacy policy link or text within the app itself.

And for the developers who think their app is the exception:

Apps that do not access any personal and sensitive user data must still submit a privacy policy.

There is no size or category exemption. A calculator with no internet permission needs one. So does a game with no accounts. The Data safety form also asks for the link before you can submit it, so you can't skip the policy and fill in the rest.

The good news is that a no-data app gets a short policy. It still has to exist, be public and say what the app does (and doesn't do) with data.

The five things Google says your policy must contain

Google lists the required contents in the same policy. Here they are, with what each one means in practice:

The second row is where most policies fall short. Developers describe what their code does and forget that the SDKs they added collect data too. If you show ads with AdMob, the Google Mobile Ads SDK collects the device's IP address (used to estimate approximate location), app interactions, diagnostics and the advertising ID, and it shares them for advertising. Your policy has to say so, because your app is the one sending it.

The last row sounds trivial, but it is a real rejection reason. A page titled "Legal" that holds your terms and privacy text together doesn't meet the labeling rule.

The URL rules

The same policy covers where the page lives:

Please make sure your privacy policy is available on an active, publicly accessible and non-geofenced URL (no PDFs) and is non-editable.

Each part of that sentence rules out a common shortcut:

• Active. The link has to load. A policy on a free host that goes to sleep, or a domain you let expire, breaks this rule months after approval.
• Publicly accessible. No login wall and no "request access" screen. A Google Doc with restricted sharing fails here.
• Non-geofenced. It has to load from every country, including the ones where Google's reviewers are.
• No PDFs. A plain web page, not a file download.
• Non-editable. Visitors can't be able to change it. A Google Doc or Notion page left open for editing fails even when it loads fine.

GitHub Pages and Google Sites technically work if you keep them public and maintained. The risk is the "active" part: these pages tend to break quietly, and Google checks the link again when you publish updates.

Where the privacy policy link goes

There are two places, and you need both.

1. Play Console. Open your app, go to Policy and programs > App content > Privacy policy, paste the URL and save. The same URL is shown on your store listing.

2. Inside the app. Google asks for "a privacy policy link or text within the app itself". A row in your settings or about screen that opens the web page is enough. If your app has a sign-up screen, a link there is a good second place.

If your app is for children, Google's help page on adding a privacy policy adds that the policy must be linked on the store listing and inside the app regardless of what data you handle.

Keep it consistent with your Data safety form

Your privacy policy and your Data safety answers describe the same thing from two angles, and reviewers compare them. If the form says the app collects device IDs for advertising and the policy never mentions ads, one of them is wrong.

The simplest way to stay consistent is to build both from the same list: every data type, which feature or SDK uses it, whether it leaves the device, and who receives it. Our Data safety form guide has that list for the most common SDKs.

Extra rules when children are in your audience

If your target age groups include children, the Families policy applies on top of everything above. The parts that change your privacy policy:

• Apps that only target children must not transmit the advertising ID or hardware identifiers such as IMEI or MAC address.
• If you show ads to children or users of unknown age, you may only use ad SDKs that are self-certified for Families.
• You have to comply with COPPA in the US and GDPR in the EU, including for the SDKs your app calls.

Your policy should say who the app is for, that it doesn't knowingly collect personal information from children without parental consent, and how a parent can ask for deletion.

A checklist before you submit

Run through this before you paste the URL into Play Console:

1. The page loads in a private browser window, with no login.
2. The title on the page says "Privacy Policy".
3. It names the app and the developer exactly as the store listing does.
4. It gives a contact email for privacy questions.
5. It lists every data type the app and its SDKs collect, and each service that receives data.
6. It says how data is protected and how long each kind is kept.
7. It explains how users ask for their data or account to be deleted.
8. It matches your Data safety answers.
9. The app links to it from a screen users can find.
10. It is a web page you control, not a PDF or a shared doc.

Common mistakes that get apps rejected

These come up again and again in rejection emails developers share:

• A broken link. The policy moved, the free host expired or the domain changed.
• A PDF or a Google Doc. Both fail the URL rule.
• A generic template that never mentions the app. Google asks for a policy that applies to your app. One that talks about "our website" and "cookies" and never names the app looks copied, because it is.
• SDKs left out. Ads, analytics and crash reporting are the usual gaps.
• No link inside the app. The Console field alone isn't enough.
• A policy that contradicts the Data safety form.

Most of these are fixed by generating the policy from what your app actually does and hosting it somewhere that doesn't move. That's also why a policy is the first page you need for a website for your Android app, and why it should explain how account deletion works if your app has accounts.