If you have ever uploaded a confidential business proposal to a PDF reader and wondered what happens to it — you should. The question is not paranoid. It is operational. Depending on which app you tapped, the contents of that document just left your phone, traveled to a vendor’s servers, were processed by a third-party text-to-speech engine, and may or may not still be cached somewhere when you close the app.

This post is not an alarm bell. It is a survey, based on each app’s own public documentation, of where document text actually goes when you ask a PDF reader to read it aloud. Where I quote a position, I am paraphrasing the vendor’s published privacy policy or product page — I am not putting words in anyone’s mouth. The goal is for you to be able to make an informed call about which architecture fits the kind of documents you actually read.

The two architectures

Every PDF-to-speech app in the market today picks one of two fundamental designs.

Cloud-TTS. The app extracts text from your PDF on the device, then uploads that text to the vendor’s servers. The vendor’s TTS engine — frequently OpenAI’s, Microsoft Azure’s, or Amazon Polly’s, sometimes the vendor’s own — synthesizes audio and streams it back. The phone receives audio frames and plays them. The server has, at minimum, briefly held the full text of your document; in many cases it logs the request and retains the text for some retention period (varies by vendor, often seven to thirty days for support and abuse purposes, sometimes longer).

The cloud-TTS design has real upsides. You get access to the latest premium neural voices the moment the vendor adds them. Cross-device sync is trivial because your library lives on the vendor’s account. New languages appear without an app update.

The downside is that your document leaves your phone. For everyday reading — articles, public papers, your own notes — most people consider this fine. For confidential material, it is a different conversation.

On-device TTS. The app extracts text from the PDF on the device and runs a local TTS model — also on the device. No text is uploaded. The model files are bundled with the app or downloaded once at install time. Audio is generated on-phone and played.

On-device has real downsides. The model files are large (a quality neural TTS model is typically 100 to 500 megabytes, sometimes more). You are limited to the languages and voices the model supports. There is no cross-device sync without separate engineering. Updates to voices require an app update rather than a server-side push.

The upside is straightforward: nothing leaves the phone. The vendor never sees the document. The app works in airplane mode. There is no per-usage cost — your phone’s CPU does the work for free.

Which architecture an app picks shapes everything about its privacy posture, its offline support, its pricing structure (because cloud TTS costs the vendor money per minute), and what happens when you close your account.

What gets sent (cloud-TTS apps)

When a cloud-TTS app processes a document, the typical data flow includes:

The full text of the document. Sometimes paginated, sometimes streamed in chunks, but in aggregate the entire text reaches the server.
Per-page rasterized images if the document required OCR and the app performs OCR server-side. Some apps OCR on-device and only upload text; some upload images.
Document title and metadata. Author, PDF creation date, page count.
Your account info. Email, subscription state, sometimes device identifier.
Usage analytics. Page count, listening duration, voice selection, playback events. This is typically what is described in privacy policies as “Service Data” or “Usage Data.”

What the vendor does with that data depends on their privacy policy and their actual engineering — and these can drift over time. The honest summary is that you are trusting the vendor not to misuse the text. For most vendors most of the time that trust is well-placed. It is still a trust relationship rather than a structural guarantee.

What the privacy policies actually say

The named apps below are the ones most readers in this category will recognize. I am summarizing the structural position each one takes, drawing on their publicly available privacy policies and product documentation. I am not quoting verbatim — privacy policies change, and the exact wording is the vendor’s responsibility. If a specific detail matters to you, read the current policy directly.

Speechify. Cloud-based by default. Documents are uploaded and processed on Speechify’s servers to generate audio. An account is required. Their privacy policy describes the data collected (account info, content uploaded for processing, usage telemetry) and their stated retention practices. Speechify uses third-party TTS providers in addition to their own voices; that means document text reaches at least one vendor and potentially more depending on which voice is selected.

NaturalReader. Cloud-based by default for the premium voices. Account required for cloud features. They offer a “personal” plan that bundles cloud TTS with limited offline access. The privacy policy describes data uploaded for processing and how it is retained.

Voice Aloud Reader and @Voice (TextHear). These two are popular Android-focused readers that primarily use the device’s built-in Android TTS engine — which is on-device for many languages. Some optional voices are cloud-based. The privacy posture is largely “on-device by default, opt-in to cloud for premium voices.” Worth verifying against the current app store listing because the architecture can vary by version.

Voice Dream Reader. Long-running iOS and macOS app. Has historically used on-device TTS for the bundled voices, with additional voices available as in-app purchases. It is in the “on-device-by-default” camp for the core experience. Apple’s privacy nutrition label on the App Store summarizes the data the app collects.

Audris. Documents are processed entirely on-device. No account is required to use the app. Document text never leaves the phone. Telemetry on what you read is not collected — the app does not know what is in your library, and neither does the developer. When you uninstall, every byte of your library goes with the app.

The pattern across the category: the household-name apps with the largest voice catalogs are cloud-based, and the apps that prioritize privacy are on-device with smaller catalogs. There are good reasons for the tradeoff in both directions; the point is to know which side of the line you are on.

Why on-device is harder (and worth it)

Building an on-device TTS app in 2026 is technically possible but operationally inconvenient. The main costs:

Install footprint. The TTS model files are not small. Audris bundles Supertonic 3 at around 404 megabytes of model weights, plus the inference runtime. That is a real download on a phone with limited storage. We make peace with this because the alternative is shipping a 5-megabyte app that needs the network for everything.

Language coverage. A cloud TTS provider can add a new language overnight by pointing at a new model on their server. An on-device app has to ship a new build, retest the runtime against the new model, and ask users to update. For an indie app with a single developer this is real engineering time.

No automatic voice improvements. When a cloud provider improves their voice quality, every cloud-TTS app gets the upgrade for free. An on-device app has to ship a new model with the next release.

Battery and thermal cost. Inference on the phone uses the CPU or NPU and warms the device on long sessions. We have done the optimization work to make this tolerable on modern phones, but it is a real engineering line item that cloud apps simply do not have.

The upsides of on-device are the structural ones that cloud cannot match. No leaks because nothing leaves the device. Consistent latency because there is no network round-trip. No internet required at all — the app works on a plane, in a basement, in a country with restrictive networking. No per-usage cost to the vendor, so the pricing model can avoid subscription pressure.

For Audris, the tradeoff comes out clear: on-device is worth it. The kind of person who reads confidential material on the train, or who lives in a place where network access is unreliable, or who simply does not want a vendor to have a copy of their documents, is the person we are building for. If you want cloud TTS with a 1,000-voice catalog, Speechify is a perfectly reasonable choice — that is the right tool for that job.

Practical guidance

If you are choosing a PDF-to-speech app, a few questions to ask:

Read the privacy policy. Actually read it. Look for language like “We process the content you upload” or “Your documents are sent to our servers” — that is the cloud-TTS architecture. Look for “Documents are processed on your device” or “All TTS is performed locally” — that is on-device. If the policy is vague, default to assuming cloud.

Check what happens when you cancel. Does the vendor delete your uploaded documents when you delete your account? How quickly? Some vendors retain content for 30 to 90 days after cancellation for backup recovery. That is normal. What you want is the policy stated explicitly so you can plan around it.

For confidential documents, prefer on-device. Legal work, internal company material, client documents, medical records, financial reports for your own business — the kind of material that has compliance implications or that you simply would not want logged. On-device is the categorical right answer for these.

For everyday reading, the trade-off is personal. A public research paper, a book chapter, an article you bookmarked — most people will not feel strongly about whether these flow through a cloud provider. The choice between cloud and on-device for everyday material is a question of voice preference and pricing model, not threat modeling.

Watch for hybrid apps. Some apps default to on-device for the standard voices and use cloud for premium voices. The architectural decision happens at the voice picker, not at install time. If you pick a “premium” voice you have just opted into the cloud path. The app may or may not surface this clearly.

The Audris position, briefly

Audris is on-device. Documents never leave your phone. No account is required to use the app. No telemetry is collected on what is in your library. The voices are bundled on-device. The transcription, structure analysis, and audio synthesis all happen on the phone.

This is a real engineering commitment, not a marketing line. It is also a constraint we accept on the product side: Audris will not have a 1,000-voice catalog, will not ship daily voice updates from the cloud, and will not offer cross-device library sync unless we figure out how to do it without breaking the privacy model.

If those tradeoffs fit you, the download links are on the home page. If they don’t, one of the cloud apps above will probably serve you better, and I would rather you pick the right tool than churn out of Audris in week two.

Your documents never leave your phone.