Why We Delete Your Audio After Transcription

May 30, 2026

We delete your audio the moment the transcript is ready. Not after 30 days, not when you close your account, not on a cleanup schedule that runs overnight. The file is removed as soon as the job finishes, automatically, without you asking.

That is not the industry default. Most transcription services hold your audio for hours, days, or indefinitely, usually under a retention window written somewhere in the fine print. We made a deliberately different choice, and this post explains the reasoning, what “zero retention” means in practice, exactly how deletion works inside Hushscript, and how to remove a transcript yourself once you are done with it. It also draws the honest line around what we do keep, because pretending otherwise would defeat the point.

The case for deletion

Holding on to customer audio creates several distinct categories of risk. Deleting it removes each one rather than mitigating it, and that difference matters more than it first appears.

Data that does not exist cannot be breached. Any storage bucket that holds recorded audio is a target, and breaches are rarely discovered the day they happen. Security incident reports consistently find that intrusions often go unnoticed for weeks or months after the initial compromise. A recording deleted within minutes of being transcribed simply is not present during that exposure window. There is no copy to exfiltrate.

The same logic applies to legal and compelled access. A subpoena, a court order, or a data request can only reach data that still exists. Audio already deleted at the time of a request is unavailable, not because anyone is withholding it or actively protecting it, but because it is gone. For a journalist with a confidential source, a lawyer holding privileged material, or a therapist recording a session, “we no longer have it” is a much stronger position than “we have it but promise to guard it.”

Deletion also closes off accidental exposure. Storage systems get misconfigured. Public-read buckets are a recurring class of security incident precisely because the mistake is easy to make and slow to notice. A file that does not persist cannot be exposed by a permissions error six months after you uploaded it.

There is a quieter benefit too. Automatic deletion demonstrates intent rather than policy. A privacy statement that says “we will delete your data on request” asks you to trust both the wording and the execution: that the request reaches the right system, that it is processed correctly, and that you remembered to send it at all. A system that deletes by default does not depend on any of that. The safe outcome is the one that happens when nobody does anything.

The trade-off is real and worth stating plainly. You cannot retrieve the audio from us later, because there is nothing to retrieve. If you ever need the original recording rather than the transcript, you keep your own copy. That is a design constraint we chose on purpose, not a gap we forgot to fill.

What “zero retention” actually means

“Zero retention” is a phrase that gets used loosely, so it is worth being precise about what it covers here and what it does not.

It refers to the audio in the speech-processing pipeline. After your file is transcribed, two things are true at once. The audio file is removed from our processing storage, and the speech engine that produced the transcript keeps no copy of it for any purpose, including model training, quality evaluation, or debugging. The engine reads the audio, returns the transcript, and discards the recording. That second part is the one most services cannot answer cleanly, because they call a third-party speech API whose own retention rules they do not control. Ours runs with retention switched off, so the answer is the same on both sides: no surviving copy of the audio.

Zero retention at the audio level is not the same as keeping no data at all, and conflating the two would be dishonest. Your account exists. Your transcript exists in your dashboard until you remove it. A billing record for the minutes you used exists, along with basic job metadata such as the timestamp, the duration, and the detected language. None of that is the audio. What ceases to exist once transcription completes is the recording itself, the one piece of data that actually carries your voice and the content of what was said.

So when you see “zero retention” on this site, read it as a specific, narrow claim about the audio and the speech engine, not a sweeping promise that nothing is stored. The narrow version is the one we can stand behind without an asterisk.

How deletion works in Hushscript

Your audio is only ever in a transient state on our infrastructure. It is never written to a permanent home and never sits in a library waiting to be opened again. The lifecycle is short and one-directional.

1. You upload. You drop a file on a page like audio to text or one of the other upload points. The audio, and only the audio, moves into a processing queue. If the file is a video, the audio has already been separated from it in your browser, so what arrives is a compact audio file with the video data left behind on your device.
2. It is transcribed. The speech engine processes the audio and returns a transcript with speaker labels and timestamps. This is the only stage where the audio is actively in use.
3. It is returned, then deleted. The transcript is written to your dashboard, and the audio file is deleted. There is no fourth stage where the recording rests in storage. It moves from processing straight to removal.

Because there is no resting stage, there is no retention window to configure or forget. The audio is present while it is being transcribed and absent immediately afterward. The technical summary fits in one line: your audio exists on our infrastructure only during the transcription window, on your device before that, and nowhere after.

For sensitive work, the most useful detail is often where the data is processed. If you are in the EU, EEA, Switzerland, or the UK, your audio is processed in the EU. Everywhere else it is processed in the US. Either way the deletion behavior is identical, and either way the recording does not outlive the transcript. You can follow the full path on the how it works page, and the private transcription page covers the data-handling specifics and how they compare with the storage-by-default norm.

A worked example: where deletion actually bites

Picture a 40-minute recorded client meeting saved as an M4A from a phone. It contains names, figures, and a few things nobody wants sitting on a stranger’s server.

You drop the file into the preview without an account. A 30-second speaker-labeled clip appears so you can confirm the two voices are being separated correctly. That preview is the only step that needs no account. To transcribe the rest you sign up, and new accounts get 30 free minutes to try. A 40-minute meeting runs past the free allowance, so you top up first; the pricing page has the per-minute cost. The full audio is then transcribed, and the moment your transcript lands in the dashboard, the M4A is deleted from our side. You relabel “Speaker 1” and “Speaker 2” to real names, export a DOCX for your records, and the transcript stays in your account, encrypted at rest, until you choose to remove it.

The point of walking through it is to show where the guarantee actually applies. At no moment is there a stored copy of the meeting audio waiting on a server after the work is finished. The transcript is the only artifact that persists, and even that is yours to delete. Compare that with the common pattern, where the same meeting would join a permanent cloud library you would have to remember to clean out later, if the tool even let you.

Removing a transcript in one click

Deleting the audio handles the recording. The transcript is the other half, and you control that one directly. After transcription, the text lives in your dashboard until you remove it.

1. Open the transcript.
2. Choose delete.
3. The transcript text is removed.

That is the whole flow. We keep no archive of deleted transcripts, so once you delete, the text is gone from our side rather than moved to a recycle bin you cannot see. Most people export first, to TXT, SRT, DOCX, or JSON with no watermark, and then delete the copy on our side, which leaves them holding the files on their own machine with nothing left on ours.

If you would rather clear everything at once, you can delete your whole account from your profile after a confirmation step. Worth knowing before you do: any minutes you have already bought are not refunded on account deletion, so spend or keep them in mind first.

The honest part: what we keep, and the encryption limit

A privacy claim is only worth as much as the parts it admits to. Two things deserve a clear, unhyped statement.

First, the residual data. We delete the audio, but the transcript stays until you remove it, and so does the small set of job metadata needed to run and bill the service. That metadata is far lower-risk than the audio, since it describes the job rather than carrying your voice, but it is not nothing, and we would rather name it than imply a clean slate that does not exist.

Second, the transcript that remains is encrypted at rest. If our storage were ever leaked, what an attacker would walk away with is unreadable ciphertext, not a searchable archive of everyone’s words. That is genuine protection against a storage breach, which is the threat encryption at rest is built for. It is also where we stop, deliberately. This is not zero-knowledge encryption. The key is held on our servers, because the app has to be able to decrypt and show you your own transcript when you open it. So we are not claiming that we cannot read your transcripts. We are claiming that a stolen database would be useless to whoever stole it without the key. Anyone who tells you a transcription tool can both display your transcripts on demand and be mathematically unable to read them is glossing over how the keys work.

That is the full honest shape of it. The audio is deleted and the speech engine keeps nothing, which removes the recording entirely. The transcript persists under encryption that defends against a leak but is not a lock against us, and you can delete it whenever you like. We would rather you understand exactly where the line sits than trust a slogan that quietly moves it.

The broader reason

The default in this industry is storage. Upload, transcribe, and keep everything in a library the user can return to. For some people that is a real feature: a podcaster building a searchable archive of their own episodes benefits from having every transcript in one place, and the content is not sensitive.

But storage is a poor default for confidential recordings. An archive of years of privileged consultations, source interviews, or internal negotiations, sitting on a third-party server, is a liability that compounds quietly over time. The longer it exists, the larger the surface for a breach, a subpoena, or a misconfiguration to land on.

Deletion is the right default when the transcript is the thing you need and the audio is only the means to get it. If you already hold the source file, on your own device or in your own storage, there is no reason for us to keep a second copy. So we do not.

For the wider risk picture, including the questions worth asking any transcription tool before you upload to it, see why your audio shouldn’t be uploaded. The deletion behavior described there is the same one covered here; that post zooms out to the full set of privacy trade-offs for sensitive recordings.