Google Play Data Safety Form for a WebView App: What to Declare (2026)

Yes, an app built from your website needs the Google Play Data safety form, and the form has to describe what your website collects, not just what the app shell does. Google's rule is that you must declare data collected or shared through a WebView your app opens when your app controls the content shown in it. The only WebViews you can leave out are ones where users browse the open web. This guide shows how to apply that rule to a WebView app, with a feature-by-feature table and an audit you can run in about an hour. Facts below were checked against Google's and Firebase's documentation in November 2026.

Does a WebView app need a Google Play Data safety form?

Yes. According to Google's Data safety help page, every app on Google Play must complete the form, including apps on closed, open or production tracks. Google states that even developers whose apps collect no user data must complete it and provide a link to their privacy policy. The exemptions are narrow: apps active only on internal testing tracks, system services and private apps.

The grace period for the form ended on July 20, 2022, so there is no longer a way to publish without it. You find it in Play Console under App content, by selecting Start under Data safety. If you are still working through the other forms in that section, our guide to publishing an app on Google Play covers each one in order.

Do I have to declare what my website collects?

If your app loads your own site, yes. Google's guidance says to declare data collected or shared through a WebView opened from your app if your app controls the content or behavior delivered there, and that you do not need to declare WebViews where users browse the open web. A branded app that opens only your website is the first case. Your login form, checkout, newsletter box and analytics all run inside the app, so the data they send off the device counts.

This is the point most first-time publishers miss. They look at the app, see no code that collects anything, and answer "no data collected". The form is about what leaves the user's device, wherever the code comes from. A mismatch is also one of the reasons apps built from websites get sent back, which we cover in why Google Play rejects WebView apps.

What counts as collected, shared or ephemeral?

Google defines the terms narrowly, and the definitions decide most of your answers:

• Collected: data transmitted off the user's device from your app, including data sent by libraries or SDKs.
• Shared: user data collected from your app and transferred to a third party, including through SDKs.
• Not collected: data processed only on the device, and data protected by end-to-end encryption that no intermediary can read.
• Ephemeral: data used only in memory and not kept beyond the request. Google says data used to build advertising or user profiles cannot be treated as ephemeral.
• Not counted as sharing: transfers to service providers processing data on your behalf, transfers required by law, user-initiated transfers or ones with prominent in-app disclosure and consent, and fully anonymized data.

For each data type you declare, Google also asks whether it is required or optional. If the app's primary functionality needs the data, Google says to mark it required. Optional means users can opt in or out, or use the app without providing it.

What should I declare for common website features?

The table maps features that websites typically have to Google's data type categories. The Play category column follows Google's published definitions. The notes column marks where we are inferring. Google does not publish a per-feature lookup, so confirm each row against your own site and tools.

For push, Firebase's Play data disclosure page says Cloud Messaging collects the app version and a Firebase user agent (OS version, device name, model, brand, form factor, installer app and Firebase SDK versions). It also depends on the Firebase Installations SDK, which generates a per-installation identifier that Firebase says does not uniquely identify a user or physical device, and you declare that SDK's data too. Firebase does not map these to Play categories itself and says you alone are responsible for your answers. How push works in this kind of app is explained in our push notifications guide.

How do I audit my WebView app step by step?

1. 1

   List every input on your site

   Go through each form, login, search box and checkout step the app can reach. Write down every field it sends.

2. 2

   List the third-party scripts

   Open your site's page source or your tag manager and note analytics, chat, pixels and embedded widgets. Each vendor has its own data disclosure.

3. 3

   List the SDKs in the app

   Push services and any other library inside the app count too. Check each provider's published disclosure and Google's Play SDK Index.

4. 4

   Match the privacy policy

   Your policy must describe the same data, uses and recipients you are about to declare.

5. 5

   Fill in the form

   In Play Console go to App content, then Data safety. Mark each type as collected or shared, required or optional, and give a purpose.

6. 6

   Export a copy

   Google lets you export and import answers as a CSV file. Keep one so you can compare after later changes.

7. 7

   Repeat when the site changes

   Because the app loads your live website, adding a new tool to the site can change your answers without any app update. Re-check whenever you do.

What does the privacy policy need to include?

Google's Prepare your app for review page says you must link to a privacy policy on your store listing and within your app. The policy must sit on an active, publicly accessible URL with a valid SSL certificate, must be accessible worldwide without a login, and must be a standard, non-editable web page rather than a PDF. It must apply to your app specifically and describe how it collects, uses and shares user data, including the types of parties it shares with. You enter the URL under App content, Privacy Policy.

Google's page does not say where the in-app link must appear. A common approach, and our inference rather than a Google rule, is a visible link in your website's menu or footer, so the app loads it like any other page. Reviewers will look for it, so make it easy to find.

What happens if my answers are wrong?

Google says it does not verify the accuracy of your declarations during review, but you alone are responsible for them, and apps that are not compliant are subject to enforcement such as blocked updates or removal from Google Play. In practice that means an inaccurate form can pass review and cause trouble later, so treat it as a living document. If you change analytics tools, add a checkout or turn on push, update the form in the same week.