Is It Safe to Upload Audio for Transcription?

Author: Hushscript | Published: May 19, 2026 | Last reviewed: July 22, 2026

Uploading audio for transcription can be reasonable when the tool, recording, and applicable rules line up. The transcription itself is only one part of the risk. What matters is what happens once the file leaves your device: where it is stored, how long it lives there, who else processes it, and whether it can be used for model training. Policies vary widely, so the safety question is really a question about the specific service you are about to trust.

This post walks through what actually happens to a file you upload, the four questions worth asking any transcription tool, how Hushscript keeps the exposure small, and the red flags that should make you close the tab. It’s an explainer, not a sales pitch. The questions apply to every tool, including ones that aren’t us.

What actually happens to your audio

When you upload a file, it doesn’t go to one place and come straight back. It moves through several systems, and the privacy question is what each one does with it.

Storage. An upload service may write your file to cloud object storage before the speech engine sees it. That storage has a retention policy, whether or not the marketing page states it clearly. The European Commission’s GDPR principles say personal data should be stored for the shortest time possible and reviewed against defined erasure limits. Ask for the actual retention window rather than inferring it from a feature list.

Processing. The audio can pass through one or more systems running speech recognition, speaker separation, and cleanup. A service may use its own engine or a processor, so check the named subprocessors and their retention terms instead of assuming the company on the upload page is the only party involved.

Training data. Speech models get better by training on real audio, and real customer recordings are valuable training fuel. Some services reserve the right to use your uploads for “product improvement” in their terms. This is rarely a clear opt-in box at upload time. It’s usually buried in the terms of service, or switched on by default with an opt-out you have to go find.

Logs. Even tools that delete the audio often keep metadata: when you uploaded, how long the file was, what language was detected, how many speakers. That metadata is far lower-risk than the audio itself, but it’s worth knowing it usually outlives the recording.

The takeaway isn’t that all of this is sinister. It’s that “upload audio, get text back” hides four or five separate decisions, and a tool that’s careful about all of them looks very different from one that isn’t.

The four questions to ask any transcription tool

You don’t need to read a company’s whole engineering blog to judge a tool. Four questions cover most of the risk, and a service that’s thought its data practices through can answer all four clearly.

When is the audio deleted?

The answer you want is “immediately after the transcript is ready,” not “within 30, 60, or 90 days” and not “when you delete your account.” Deletion that needs you to take action means the audio persists by default, and defaults are what actually happen. A fixed retention window of weeks or months means there’s a copy of your recording sitting on a server for that entire time, available to anyone who can reach the bucket.

Does the speech engine keep a copy?

If the service uses a third-party speech API, your audio passes through that vendor too. “We don’t store your audio” from the company you signed up with is not the same as the underlying engine not storing it. Ask whether the speech provider also deletes immediately, or whether it retains audio under its own separate policy. This is the step most people miss, because it’s invisible from the outside.

Is the audio used for training?

The privacy policy is the binding document, not the landing page. Look for specific language about whether recordings are used for model training, fine-tuning, or evaluation. If the policy says something vague like “to improve and develop our services,” assume that includes training until they say otherwise. Ambiguity in a privacy policy tends to resolve in the company’s favour, not yours.

What’s stored, and is it encrypted?

Even with the audio deleted, the transcript usually stays. That’s the thing you came for. A transcript of a confidential conversation is sensitive in its own right. Ask whether stored transcripts are encrypted at rest, so that a storage breach would expose unreadable ciphertext instead of a searchable archive of everything anyone ever transcribed.

These aren’t gotcha questions. A tool that answers all four plainly has earned a closer look. A tool that dodges them has told you something too.

How Hushscript keeps the exposure small

The design principle behind Hushscript is minimal contact: your audio should spend as little time as possible on any server outside your own device, and what does get stored should be unreadable if it ever leaks. That’s the privacy wedge, and it’s worth being concrete about how it works.

Your video never uploads. If you drop a video file, Hushscript prepares its audio track in your browser before anything is sent. A compatible track is copied out without re-encoding; conversion runs locally only when the track needs it. What reaches the transcription service is an audio-only upload with the video data left behind. The video itself stays on your device from start to finish.

The audio is deleted the moment the transcript is ready. There’s no 30-day grace period, no backup bucket, no cold-storage tier. Deletion is automatic at completion. It isn’t something you request, and it doesn’t depend on you remembering to. The audio is in a transient processing state from upload to transcript, and then it’s gone.

The speech engine retains nothing. The engine that does the transcription does not keep your audio for training, evaluation, or debugging. It processes the file and discards it. That answers the subprocessor question directly for Hushscript instead of leaving it implicit in an application-level deletion claim.

Your transcripts are encrypted at rest. The transcript that lands in your dashboard is encrypted where it’s stored. If our storage were ever leaked, what an attacker would get is unreadable ciphertext, not a readable archive of your words. To be precise about the limit of that claim: this is leak protection, not zero-knowledge. The key is held on our servers so the app can decrypt and show you your own transcript, so we are not claiming we can’t read it. We’re claiming that a stolen database would be useless without the key, which is the threat encryption-at-rest is actually meant to address.

About certifications. Hushscript doesn’t hold SOC 2 or other formal compliance certification. The approach is to keep the exposed surface small in the first place (extract audio in the browser, delete it on completion, encrypt what’s stored) rather than to build a large store of recordings and then certify the controls around it. If a compliance certificate is a hard requirement for your work, that’s a fair reason to choose a certified vendor instead; it’s better to know that up front than to assume it.

The net effect is a short data footprint. Your audio exists on our infrastructure only during the transcription window. Before that, it’s on your device. After that, nowhere, and the transcript that remains is ciphertext at rest. You can see the full flow on the how it works page, and the private transcription page goes into the data-handling specifics.

A worked example: a confidential interview

Say you’re a journalist with a 50-minute recorded interview, in MP4 because you filmed it on a phone. The source asked to stay anonymous. Here’s what happens, step by step, and where the privacy guarantees actually bite.

1. You drop the MP4 into the preview. No account yet. The page reads the file in your browser and prepares the audio locally. The 1.8 GB video never leaves your laptop; only an audio-only upload is prepared for the next step.
2. A 30-second speaker-labeled preview appears. You see the opening exchange already split into “Speaker 1” and “Speaker 2,” so you can confirm the diarization is sensible before committing. This preview is the only genuinely no-account step.
3. You sign up to transcribe the rest. Transcription is gated, so it needs an account. New accounts get 30 free minutes to try: instantly when you validate a card with a $1 hold that’s authorized and then released right away, never charged, or with your first purchase if you use a payment method available in your country. A 50-minute interview runs past the free 30, so you’d top up; the pricing page has the per-minute cost.
4. The full audio is transcribed, then deleted. The audio file is processed and removed the moment your transcript is ready. There’s no copy of your source’s voice left on a server.
5. You relabel and export. You rename “Speaker 1” to the interviewer and “Speaker 2” to the source’s pseudonym, then export to DOCX for the editor and keep a TXT for your notes. The transcript sits in your dashboard, encrypted at rest, until you delete it.

The point of the example: at no stage is the raw video on a server, the audio outlives transcription, or the stored transcript readable by anyone who breaches the storage without the key. That’s the difference between “we transcribed your file” and “we kept your source’s recorded voice indefinitely.”

Common worries, answered

A few situations come up often enough to address directly.

“My file is huge: does that mean a long, risky upload?” A large video is prepared locally first, because the video stays on your device and only its audio is sent. Compatible tracks are copied without re-encoding, while conversion is reserved for files that need it. There’s no file-size limit – even a very large video is prepared right in your browser, as long as the recording is within 10 hours.

“What if the transcript has things I don’t want stored at all?” Use private mode for speech recognition only and a password-protected archive result without saving the transcript in your account. For normal transcripts, export what you need and delete the transcript when you no longer need it.

“I only have an audio file, no video – does browser extraction still matter?” For a plain audio file there’s no video to hold back, so that specific protection doesn’t apply. The ones that still do are the big ones for sensitive work: the audio is deleted after transcription, the engine keeps nothing, and the transcript is encrypted at rest.

“Is a free tool automatically less safe?” Not automatically. But if a tool is entirely free and there’s no obvious way it makes money, it’s worth asking what’s being monetised. Sometimes the answer is the data you’re contributing. A paid or pay-as-you-go tool at least has a funding model that doesn’t depend on mining your uploads.

Stored archive vs. transcribe-and-delete

There are two honest models for a transcription tool, and which one fits depends on what you’re transcribing.

A stored-archive tool keeps your audio and transcripts in a searchable library you can return to months later. That’s genuinely useful if you’re building a personal knowledge base of your own recordings and the content isn’t sensitive, like a podcaster archiving their own episodes. The cost is that a growing pile of your recordings lives on someone else’s server.

A transcribe-and-delete tool, like Hushscript, treats the transcript as the deliverable and the audio as a means to get it. The audio is deleted on completion and the transcript is yours to export and remove. That’s the right model when the recording is confidential and you already have your own copy of the source file, since there’s no reason for the tool to keep one too.

Neither is wrong. But for legal recordings, interviews, therapy notes, or anything with an anonymous source, the second model removes a liability that the first one accumulates over time.

Red flags to watch for

When you’re evaluating any tool, a few signals are worth treating as warnings.

Vague retention language. “We store your files for a reasonable period” or “files may be retained to improve our services” are not commitments. “Reasonable” can mean anything, and “improve our services” frequently covers training.

Training clauses hidden in the terms. Check the “Acceptable Use,” “Content,” or “License” section of the terms of service, not just the privacy policy. Some tools grant themselves a broad license to use submitted content however they like, which can quietly include training a model on it.

No clear answer to a direct question. If support can’t say plainly when audio is deleted or whether recordings are used for training, that silence is itself the answer.

Free with no visible funding model. If a tool is fully free and the economics aren’t obvious, consider whether the product being sold is the data you’re handing over.

Indefinite storage paired with a paywalled export. A tool that stores your audio forever but charges to export the transcript is designed to keep you dependent on its storage, not to hand you control of your own content.

For interviews, legal recordings, or any audio where the content is sensitive, the question that matters isn’t whether the transcript is accurate – it’s whether the audio that produced it stays yours. The private transcription page lays out how Hushscript’s approach compares to the default.

And if you want the deletion mechanics specifically (when it happens, what counts as “deleted,” and why we made that the default), why we delete your audio after transcription covers it in detail.