Google Play Data Safety Form Generator (Free, 2026)

Google Play Data safety answer generator

Answer a few questions about your app and the SDKs in it, and get the Data safety declaration row by row — data type, collected or shared, required or optional, and the purposes — with the reason each row is there, so you can check it rather than trust it.

Runs in your browser — nothing is uploaded

What Play is actually asking

The Data safety form has two halves. The first is three questions about your practices: whether the app collects or shares any of the listed data types at all, whether everything it collects is encrypted in transit, and whether people have a way to request deletion. The second is a row for every data type you do collect, and that is where the work is.

For each type Play asks whether it is collected, shared, or both; whether it is processed ephemerally; whether collection is required or people can choose; and which of seven purposes it serves. Fourteen categories, roughly thirty types, and the answers become a public card on your listing.

The SDKs are the hard part

Most wrong declarations are not dishonest — they describe the code the developer wrote, and miss the code they linked. Google counts data transmitted by any library or SDK as collected by your app regardless of where it goes, so the question is never "what do I store", it is "what leaves the device".

One example, from Google’s own SDK disclosure: linking the Mobile Ads SDK means declaring the advertising ID and app set ID, product interactions and diagnostics — collected and shared, for advertising, analytics and fraud prevention. None of that appears anywhere in your source.

This tool asks which SDKs are in the build and writes their rows for you, marking sharing where the vendor’s own disclosure says the third party decides how the data is used. Every row prints the answer that produced it, so you can strike the ones that do not apply instead of accepting a list you cannot audit.

What you do not have to declare

Google names three exemptions, and they are worth knowing because they are the difference between a short declaration and a long one:

On-device only: data your app accesses but only processes locally and never sends off the device.
End-to-end encrypted: data that does leave the device but is unreadable to you or anyone other than the sender and recipient.
Ephemeral: data held only in memory, retained no longer than the real-time request needs. This one is a per-row answer, and the generator leaves it at No — say Yes only where it is genuinely true.

It has to agree with your privacy policy

Play compares the two. A declaration listing an analytics SDK your policy never mentions, or a policy promising deletion your form says you do not offer, is a policy violation rather than a rejection you can fix by re-uploading — and enforcement can reach the whole developer account. The free privacy policy generator asks the same questions, so you can produce both from one set of answers and read them side by side.

Need the URL, and the terms of service too?

This tool gives you the document. Edok Studio gives you the link the stores ask for: it writes both your privacy policy and your terms of service with AI from one short brief, and publishes each at a permanent public HTTPS URL you can paste straight into App Store Connect and Play Console. Edit and re-publish whenever the app changes — the URL stays the same. Included on the free plan; your own domain on the top plan.

Publish it free — no card How the hosting works

Frequently asked questions

What is the Data safety section?

It is the declaration every Google Play listing has to carry: what user data your app collects, what it shares with third parties, why, whether people can opt out, whether it is encrypted in transit and whether they can ask for it to be deleted. Play renders it as the "Data safety" card on your store listing, and you cannot publish or update an app without completing it.

Why do the SDKs matter so much?

Because the form asks about data leaving the device, not about code you wrote. Google is explicit that data transmitted by a library or SDK counts as collected regardless of where it goes — so linking AdMob puts you on Device or other IDs, App interactions and Diagnostics as both collected and shared, whether or not your own code touches any of it. This is the single most common reason a declaration is wrong.

What does not have to be declared?

Three things, in Google’s own words: data accessed by your app that is only processed locally on the device and never sent off it; data sent off the device but unreadable to anyone other than the sender and recipient because of end-to-end encryption; and data processed ephemerally — held in memory no longer than is needed to serve the request in real time. A camera that never uploads and an on-device search index are genuinely out of scope.

What counts as "shared"?

Transferring data to a third party, which is different from collecting it. An analytics provider processing on your behalf under your instructions is usually collection rather than sharing; an ad network deciding for itself how to use the advertising ID is sharing. When an SDK vendor publishes its own Play data disclosure, follow that — this tool does, which is why the ad rows come out marked Shared.

Can I import this into Play Console as a CSV?

Not from here, and no honest tool can offer it. Play’s CSV is keyed by question IDs that only exist in the template you export from your own console, and a file written from the outside fails to import. Export the sample CSV in Play Console, then fill it in from these answers — or just work through the form on screen with this open beside it.

Does it have to match my privacy policy?

Yes, and Play checks. A declaration that contradicts your policy — or a policy that never mentions the analytics SDK your declaration lists — is a policy violation rather than a rejection you can fix by re-uploading. Generate both from the same set of answers and read them side by side before you submit.

Does this send my answers anywhere?

No. The form runs entirely in your browser and the declaration is assembled on the page — nothing is submitted, stored or logged. There is no account, and there is nothing for us to keep.