How to check whether a transcript was made on-device or in the cloud

This is a different question from "why did my transcription go to the cloud," which is about the mechanism that decides, going forward. This one starts from a transcript you already have, sitting in your library right now, and asks which path made it — after the fact, with no test run at the time.

Why the transcript itself gives you nothing

Apps built on Apple's Speech framework display the result of a transcription request the same way regardless of which attempt produced it. The on-device pass and the server retry both hand back plain text through the same call, and the interface has no reason to remember which one it was — it is showing you the words, not the route they took. Exporting does not add that information either: a TXT or JSON export carries the transcript itself and the ordinary fields around it, not a record of which pass produced the words. There is nothing to inspect on the file that would settle this.

What actually leaves a trace, and its limits

The App Privacy Report, cross-referenced by time

If you had already turned this on in Settings → Privacy & Security before the recording in question, and it still falls inside the rolling seven-day window the report keeps, you can compare its timestamp for an Apple domain against roughly when you made that recording. That is real evidence, not a guess — but it only exists if the report was already running, only covers a week back, and a timestamp lining up is circumstantial for one specific transcript rather than proof, since the report logs that the app reached a domain, not which recording triggered it.

Cellular or Wi-Fi data usage totals

Settings → Cellular (or Wi-Fi) lists how much data an app has used since the counter was last reset. It is a real number, but it is a running total, not a timestamped log of individual requests — useful for noticing that some network use happened somewhere in that window, not for isolating one recording inside it.

How long the transcript took to come back

An on-device pass never leaves the phone, so it tends to be quick; a server retry adds a network round trip on top of that. This is a hint at best. A long recording being chunked, or a phone busy with something else at the time, can slow down a purely local pass too, so elapsed time alone does not distinguish the two reliably.

What would give you certainty, and why it cannot reach backward

The one test that actually settles this is putting the phone in Airplane Mode and transcribing with no network available: text back means the on-device pass handled it on its own, because there was nowhere else for the request to go. If the recording in question still exists as audio, and the language is set correctly, running transcription again works exactly like the first attempt — the same on-device-first pass, the same fallback rule — so you can re-run that specific clip in Airplane Mode today.

What that re-run cannot do is tell you what happened the first time. It tells you what would happen today, on this phone, with whatever on-device language models happen to be present right now — and that is not necessarily the same set that was present when the original transcript was made. A language added, a phone restored, or simply time passing can all change what is installed. A clean result today is a real answer to "would this audio transcribe locally now," not to "did it, back then."

The honest limit

For a transcript that already exists and was not tested at the time, there is no fully reliable way to know which path made it. The App Privacy Report and data-usage totals give circumstantial evidence at best, and a fresh re-transcription in Airplane Mode answers a question about today rather than about the day the transcript was actually produced. Anyone telling you otherwise is overselling what these tools can show.

If it matters going forward, test it before it matters

The test that actually works is cheap and takes thirty seconds — put the phone in Airplane Mode, transcribe, see if text comes back — but it only works run in advance, on the specific recording you care about, in the language and room it is actually going to happen in. For anything where the answer genuinely matters — a sensitive conversation, a specific language you are unsure has its model downloaded — that is worth doing once before you need the certainty, rather than trying to reconstruct it afterward.

How Voice Studio handles this

Voice Studio always attempts on-device transcription first, across all 38 of its transcription languages, and only retries with on-device recognition turned off if that first pass comes back empty or throws an error — the same rule for a first attempt or a re-transcription. It has no account, no server of its own and no analytics SDK, so the only domain that can ever show up in the App Privacy Report belongs to Apple's speech service, and only on the recordings where that retry actually ran. If a specific recording still exists and you need to know today, transcribing it again in Airplane Mode gives you a direct answer for right now; for anything already in the past without a test attached to it, that answer just is not recoverable, and we would rather say that plainly than imply a certainty the tools do not give.

Common questions

Does the exported TXT or JSON file record which path made the transcript?

No. The export carries the transcript text and the ordinary fields around it, not a record of whether the on-device pass or the server retry produced the words.

If I re-transcribe an old recording in Airplane Mode and get text back, does that prove the original transcript was made on-device?

It proves that clip transcribes locally today, on this phone, with whatever language models are currently installed. It does not prove what happened the first time, because what is installed can change between then and now.

Is there any setting that logs which path every transcription used?

Not as a per-recording record. The closest thing is the App Privacy Report, which logs domains an app contacted over a rolling seven days — useful for cross-referencing by time, but not a log tied to individual recordings.

What is the one reliable way to know, if I can still choose to test it?

Airplane Mode, run before or during the recording you care about. If text comes back with no network available, that pass was local — that is a direct test, not an inference.