Why does an exported transcript show strange characters on iPhone?

It is a specific, disorienting kind of broken: the transcript looks completely normal in the app, exports without any error, and then a name in Ukrainian or a word in Hebrew comes out the other end as a run of question marks or empty boxes once the file is opened somewhere else — a Windows laptop, an older program, a spreadsheet import. Nothing about that looks like a typo or a mishearing. It looks like the file itself broke on the way over, which is a reasonable thing to suspect and almost never what actually happened.

What a text file actually is, underneath

A plain text file has no label inside it that says which alphabet its bytes are supposed to spell out. It is just a sequence of bytes, and every program that opens it has to assume a mapping from those bytes to the letters and symbols it shows you — a character encoding. Get the assumption right and the file reads exactly as written. Get it wrong and the program is not making anything up; it is faithfully displaying the wrong character for every byte where its assumption and the file's actual encoding disagree.

Almost everything written for iPhone, Mac, Android or the modern web makes the same assumption: UTF-8, a single encoding that can represent every script an iPhone can transcribe into — Hebrew, the Cyrillic used for Ukrainian and Russian, Chinese characters, Japanese kana and kanji, Korean hangul, and every accented Latin letter in French, Spanish or Portuguese. It is the closest thing text has to a universal default today, which is exactly why this problem has become rarer than it used to be, and also why it still surprises people the few times it happens.

Why it is only some of the words that break

The tell that this is an encoding mismatch and not a transcription error is which characters survive. Plain letters, digits and ordinary punctuation are represented identically in UTF-8 and in nearly every older encoding still in use — that overlap is deliberate, going back decades, and it is why an English sentence with no accents can pass through almost any mismatched program completely unharmed. It is specifically the characters those encodings disagree about — an accented é or ñ, and every non-Latin script — that come out as a question mark, a box, or a short run of unrelated symbols. If a whole transcript is garbled edge to edge, that points somewhere else; if it is only the accented letters and the non-Latin words that broke while everything else reads fine, that pattern is the signature of an encoding mismatch specifically.

This is also how to tell it apart from a recognizer actually getting a word wrong. A mistranscribed word is still a real, plausible word — the recognizer heard something and wrote down its best guess, wrong but coherent. A garbled character is not a guess at all; it has no relationship to what was meant, it shows up in exactly the same broken form every time that byte sequence occurs, and it is a property of whatever program is displaying the file, not of what the app actually wrote into it.

Where this still happens, now that UTF-8 is the default almost everywhere

Modern, general-purpose apps rarely trigger this just by opening a text file — Notes, Mail, Messages, a browser, or a word processor on a current phone or computer read UTF-8 correctly without you doing anything. Where a wrong assumption still shows up is more often on the way into a narrower tool: a spreadsheet's "import text file" dialog that offers a choice of encoding and defaults to something regional rather than UTF-8, or an older script or program built assuming a single-byte, Latin-only encoding because whoever wrote it never expected the input to contain anything else. The transcript itself was never at fault in either case — the mismatch happens at the specific doorway it was carried through.

Fixing the one copy that shows it

The underlying transcript, still sitting in the app that produced it, is untouched by any of this — only the one exported copy, read by the one program that guessed wrong, displays incorrectly. That points straight at the fix: reopen the file and tell the receiving program explicitly which encoding to use, where it offers that option. A text editor with a "reopen with encoding" command, or a spreadsheet's import wizard with an encoding dropdown, both let you pick UTF-8 directly instead of accepting whatever the program guessed by default. If the tool gives you no such option at all, re-exporting from the source and pasting the text directly into the destination, rather than opening the saved file, sidesteps the guess entirely — a paste carries the actual characters across, with no file-reading assumption in between.

How Voice Studio handles it

Both the TXT and the JSON export write plain UTF-8 text, the same encoding essentially every current iOS, Mac, Android or web tool already assumes when it opens a file — a transcript in Hebrew, Ukrainian, Chinese, Japanese, Korean or accented French or Spanish opens correctly in the overwhelming majority of places it is likely to land. If one particular destination still shows the wrong characters, that is a fact about what is reading the file there, not about what was written to it — telling that program to read the file as UTF-8, wherever it lets you choose, is what actually fixes it. Nothing about a display glitch on the way in affects the transcript sitting in the app itself, which stays exactly as it was transcribed.

Common questions

Does this mean the transcription got the word wrong?

No. A mistranscribed word is still a real word, just the wrong one. Garbled characters — question marks, boxes, or symbols with no relation to the original — are a program reading the file with the wrong encoding assumption, a completely different kind of problem from the recognizer mishearing something.

Why do only some letters turn into symbols and not the whole transcript?

Plain letters, digits and ordinary punctuation are represented the same way in UTF-8 and in almost every older encoding, so they read correctly regardless of which one a program assumes. It is specifically accented letters and non-Latin scripts — where encodings disagree — that come out wrong.

Is my transcript damaged if I see this?

No. The transcript inside the app is unaffected — this happens to one exported copy, in whichever program opened it with the wrong assumption. Re-exporting or reopening that copy with the encoding set to UTF-8 fixes it.

How do I fix a transcript that already shows garbled characters?

Reopen it in a program that lets you choose the encoding explicitly and pick UTF-8, if that option exists. If it does not, re-export the transcript from the app and paste the text directly into the destination instead of opening the saved file.