Blog

Why We Delete Your Audio After Transcription

Author: Hushscript | Published: June 1, 2026 | Last reviewed: October 14, 2026

Hushscript removes its transcription-audio copy after processing. Not after 30 days, not when you close your account, not when you remember to ask. The removal is automatic, and the transcript is what stays with you.

Retention policies vary across transcription services, and the difference matters. The ICO’s storage-limitation guidance gives the useful principle: personal data should not be kept longer than its purpose requires. Hushscript made a deliberately narrow choice for audio, and this post explains what Hushscript deletes, what it keeps, how deletion works, and how to remove a saved transcript when you are done with it.

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 that Hushscript has already removed after processing is not there to be taken during that exposure window.

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 Hushscript deletes, and what it does not

“Deleted” is a word 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 separate things happen. Hushscript removes its transcription-audio copy, and it asks the speech provider to delete its transcript copy once the job is finalized. If that request fails, removal can be delayed, so Hushscript does not promise instant erasure on the provider’s side. A service using an external processor has to answer for that processor too, and an application-level deletion claim does not settle the subprocessor question by itself. What does not change is Hushscript’s own commitment: it never trains models on your recordings.

Removing the audio 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 Hushscript removes after processing is its copy of the recording, the one piece of data that actually carries your voice and the content of what was said.

So when this site says Hushscript removes your audio, read it as a specific, narrow claim about the transcription-audio copy, not a sweeping promise that nothing is stored or that the speech provider’s side clears instantly. The narrow version is the one we can stand behind.

How deletion works in Hushscript

Hushscript keeps your audio only to transcribe it. It 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, its audio has already been prepared in your browser (copied without re-encoding when compatible, converted locally only when required), so the video data stays 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 saved, then removed. The transcript is written to your dashboard, and Hushscript removes its audio copy. There is no fourth stage where the recording sits in a library; it moves from processing to removal.

Because there is no resting stage, there is no audio retention setting to configure or forget. The audio is there for the job and removed after processing. In short: Hushscript’s transcription-audio copy exists for the job, your source file stays on your device, and the transcript is what persists.

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 Hushscript removes its audio copy after processing. 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 5-minute 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. Full transcription needs an account and enough available minutes. Eligible personal accounts can receive 30 free minutes once, after card verification or with their first purchase. A 40-minute meeting runs past the free allowance, so you top up first; the pricing page has the per-minute cost and the free-minutes terms. The full audio is then transcribed, and once your transcript is saved to the dashboard, Hushscript removes its copy of the M4A. 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 delete it or a retention rule removes it.

The point of walking through it is to show where the guarantee actually applies. After processing, Hushscript removes its stored copy of the meeting audio. The transcript is the artifact that persists, and even that is yours to delete. A service built as a searchable recording archive makes a different trade-off; read its retention controls before choosing that model for sensitive work.

When you do not want a saved transcript

Use private mode. It runs speech recognition only, skips saved transcript storage and post-processing AI, and returns a password-protected archive instead of keeping the transcript in your account.

Removing a normal transcript

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, and it also returns a downloadable receipt recording what was removed and when. What that receipt does and doesn’t prove is covered below. Deleting a transcript removes its text rather than moving it to a recycle bin you cannot see. If you already know you do not want a saved transcript, private mode is the cleaner path.

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.

Retention windows: deletion on a schedule

Not every transcript gets deleted by hand. Set an account-wide default: keep everything until you delete it yourself, or auto-remove transcripts after 7, 30, 90, or 365 days. Hushscript follows that schedule without you having to remember to act. Any single transcript can also carry its own auto-delete date that overrides the account default, for the one file that needs a shorter shelf life than the rest, or a longer one.

These windows govern the saved transcript text. Your audio follows the simpler rule above: it is removed after processing, whatever window you set. Scheduled removal doesn’t download a receipt when it runs, but it stores one on the deleted entry in your transcript list, where you can download it later.

Proof of deletion: what a receipt can show

“Proof of deletion” is what people look for after asking a service to delete their audio and wanting something more solid than a privacy policy. No transcription service, Hushscript included, can hand you cryptographic proof that a file exists nowhere on its infrastructure. Proving a negative is not something a vendor can demonstrate to an outside party, so a claim of deletion comes down to trusting the vendor, checkable at most against its own logs. NIST’s media-sanitization guidance shows the same scoping problem: sanitization depends on the medium, method, verification, and disposition process, and a user-facing record cannot inspect all of those layers.

What Hushscript gives you instead is a deletion receipt. Dedicated transcript, AI artifact, and account deletion flows return a downloadable JSON file recording what was removed and when. It is a narrower, more checkable claim than a general promise, and it is useful as a timestamped note to attach to your own files, such as a case file.

It is also limited. The receipt is Hushscript’s own account of what it did on its side. It is not an independently audited certification or a third-party data deletion certificate, and it cannot speak for a processor’s systems. It records only the Hushscript deletion named in the file. If your situation requires independently certified deletion, that is a stronger, different guarantee than this receipt provides.

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. Hushscript removes its audio copy, 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. Hushscript removes its audio copy and asks the speech provider to delete its transcript copy, which takes the recording out of the picture. 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.