Third-Party Keyboard Privacy Risks: What Android Keyboards Can Collect

A third-party keyboard can read every character you type, and a keyboard with internet access can send it anywhere. The real risk is what happens after your keystrokes leave the phone.

Judge any keyboard on three things. Its Play Store Data safety label, its cloud settings and permissions, and its vendor's history.

What a Third-Party Keyboard Can Actually See

Android tells you itself. When you enable a new keyboard, the system warns, "This input method may be able to collect all the text you type, including personal data like passwords and credit card numbers." That string ships in Android's own settings code, so it is the platform's position, not a paranoid blogger's.

The keyboard app runs as the Input Method Editor, or IME. That is the layer sitting between your fingers and every text field on the phone. Every character typed in every app passes through it first.

Two things install a keyboard. One is the app's INTERNET permission, which Android grants silently at install time with no prompt (unless you run GrapheneOS or another hardened custom OS, which can require explicit permission grants). The other is your selection of it as the active input method.

Once selected, there is no separate "full access" toggle the way iOS has. The access is total from the start.

Some things stay out of reach without extra permissions. Photos, files, contacts, and the microphone all sit behind separate permission prompts.

And passwords typed through password manager autofill never pass through the keyboard at all. Android's autofill framework fills the field directly, so the credential never touches the IME (Android documents this on its autofill framework page).

If you are choosing between keyboards right now, my guide to private Android keyboards covers the options that minimize this access in the first place.

Where the Risk Actually Materializes

The keystroke access itself is not the danger. Android warns you about it every time you enable a keyboard. The danger is what happens after data leaves the device, and there are three channels for that.

Deliberate collection comes first. Kaspersky's analysis of Gboard and SwiftKey found per-word metadata leaving the device, including language, word length, timing, and which app was in focus. The advertising ID traveled alongside it.

Neither keyboard was observed capturing raw input content, but that metadata is enough to build a profile of a person.

Transit exposure is the second channel. The Citizen Lab's "Not-So-Silent Type" report tested nine cloud-based pinyin keyboards and found transmission flaws in eight of them. A passive network eavesdropper could fully recover keystrokes from those eight.

The researchers estimated up to one billion users were affected, most of them on popular Chinese keyboards.

Storage leaks are the third channel. The ai.type breach of 2017 left an unsecured database holding 577 GB of user data exposed. Roughly 31 million users' records sat in it, including more than 20 million unique email addresses, phone numbers, and social profile details.

Much of that data was never needed for a keyboard to function.

Real Incidents That Show the Pattern

These are not hypotheticals. Each of the following played out in public.

• ai.type, 2017. The unsecured database described above was discovered by Kromtech and covered by the BBC. The Have I Been Pwned record confirms the scale.
• SwiftKey, 2016. Some users' prediction bars started suggesting other people's email addresses. Microsoft paused cloud sync while it investigated.
• Go Keyboard, 2017. AdGuard's researchers found the app reporting Google account email, location, and device identifiers without consent, and downloading remote code (AdGuard). The violations stopped after disclosure.
• SKKU keylogger study, 2015. Researchers at Sungkyunkwan University built a proof-of-concept keylogging keyboard that used only the INTERNET permission. It passed Google Play review within hours. Their audit of 139 keyboards found 84 carried the INTERNET permission and could be misused the same way (paper).

That last one matters most. Store review checks what an app does on the phone. No automated scan sees what a developer does with data on their own servers.

How to Evaluate a Third-Party Keyboard Before Installing

Google's Data safety section on a Play Store listing is the fastest screening tool available. Reading it properly takes about five minutes, and this is the procedure I follow for every keyboard I consider.

1. Open the listing and find the Data safety section. Ask whether the app declares "Data collected" or "Data shared" in any category. For a keyboard, any declared collection is a choice the developer made, not a technical necessity.
2. Look specifically at "Data collected or shared for advertising or marketing." A keyboard that shares typing-derived data for advertising fails my test immediately.
3. Check whether the label says data is "encrypted in transit" and whether the developer offers "a way to request data deletion."
4. Cross-check the label against the vendor's privacy policy. The label is self-declared, and Google audits it after publication, not before. The policy is where you catch discrepancies.
5. Search the vendor's name together with "breach" or "scandal." A vendor's track record is the best single predictor of its future behavior.
6. On the phone itself, open the app's permission list. Contacts, camera, or microphone requests from a keyboard are red flags. Then open the keyboard's own settings and find the cloud or account toggles, usually named "Share usage statistics," "Help improve," or cloud learning.

The Data safety label has one weakness worth knowing. It is self-reported by the developer, and Google's developer policy makes the developer responsible for its accuracy. Treat the label as the vendor's opening statement, not as an independent audit.

Settings That Reduce the Risk After You Install

If you keep a third-party keyboard, three settings change its behavior more than anything you did before installing.

Disable the cloud features first. In Gboard, for example, switching off "Share usage statistics" stops the word-length and app-usage reporting Kaspersky documented. The keyboard keeps working with local prediction only.

Use password manager autofill for credentials. Android's autofill framework fills password fields directly, so your passwords never pass through the keyboard buffer.

Consider an app firewall. NetGuard or TrackerControl can block a keyboard's internet access outright, which works well for keyboards that predict on-device.

For sensitive apps, switching to a different keyboard for those sessions is a form of compartmentalization. It costs a little convenience and buys real separation.

When to Skip a Third-Party Keyboard Entirely

Some keyboards earn their install with features that run entirely on your phone. If the one you want earns its place with cloud features you would disable anyway, the math stops working. In that case the default keyboard, or an open-source on-device alternative, wins.

My Android keyboard recommendations close with the combination I actually run. If a candidate fails the evaluation above, that list is where I would look next.