Audio files are not uploaded to any server when you cut them in a browser-based audio cutter: the file is read, decoded, trimmed, encoded, previewed, and downloaded entirely inside the current browser tab. The question "are audio files uploaded when I cut audio" usually comes from a real privacy concern — voice memos, unreleased music, client recordings, and interviews can be sensitive, and you have every right to know whether your audio leaves your machine. With a tool that uses the Web Audio API to decode and the browser's own file APIs to read and download, the answer is straightforward: nothing is transmitted. The Audio Cutter at Lizely reads your chosen file with the browser, decodes it via Web Audio, lets you pick start and end times in seconds, and exports an uncompressed PCM16 WAV as a local download — all without a server round-trip. Temporary blob URLs support the on-page player and the download button, and those URLs are released the moment you pick a new file, replace the cut, or close the tab.
What "Uploaded" Actually Means for an Audio Cutter
Online tools sometimes mix local and remote work behind a single button, so the word "uploaded" is worth defining before you trust a privacy claim. An audio file is uploaded when a copy of the source bytes — or the decoded audio inside it — is transmitted from your browser to a remote server over the network. That transmission is what exposes a recording to the service operator, to logs, and potentially to anyone with access to those logs. A browser-based audio cutter, by contrast, reads the file with the browser's own File API, hands the bytes to the Web Audio decoder, and never makes an outbound HTTP request with the audio payload.
When you search "are audio files uploaded when I cut audio," the real worry is usually one of three things: a confidential voice memo leaking, an unreleased song being copied, or a recorded interview leaving your laptop. All three are legitimate. The way to answer the question is to look at what the tool actually does with the file: does it send the bytes somewhere, or does it operate on a local object URL plus an in-memory audio buffer? The Audio Cutter belongs to the second group — every stage happens against local resources the browser allocates for the current page.
How Local Audio Cutting Works in the Browser
Browser-based trimming relies on three pieces of web platform technology working together. First, the file picker exposes the file to JavaScript as a File object held in memory; the browser does not transmit it. Second, the MDN BaseAudioContext decodeAudioData method turns the compressed bytes into an AudioBuffer — raw floating-point samples you can read by channel and frame. Third, a temporary URL.createObjectURL blob URL gives the on-page player and the download link something to point at without round-tripping through a server.
When you press cut, the tool converts your start and end seconds into frame indices at the decoded AudioBuffer sample rate. The start frame is included and the end frame is excluded, so the selected range covers the frames between the rounded start and end indices in every channel. Each Float32 sample in that range is clamped to the −1 through 1 PCM range and rewritten as a signed little-endian 16-bit integer. The exporter writes a fresh 44-byte RIFF/WAVE header followed by the interleaved PCM data — a brand-new WAV file, not a re-encoded version of the source.
Cut Audio Without Uploading: Step by Step
- Open the Audio Cutter in your current browser. No account or sign-in is required, and the page makes no network request for your audio at any point.
- Click the file picker and choose a browser-decodable audio file within the displayed file and decoded-audio limits. The page accepts common MP3, WAV, M4A, AAC, Ogg, WebM, and FLAC names and MIME types; whether a given file actually decodes depends on what your specific browser and operating system support.
- Wait for Web Audio to finish decoding. The page displays the decoded duration, sample rate, channel count, and frame count — these describe the working buffer, not necessarily the source file's encoded rate.
- Enter a non-negative start time in moments and a later end time that does not exceed the decoded duration. Both fields snap to the nearest decoded sample frame, and a selection that rounds to less than one frame is rejected.
- Select "Cut and export WAV". The tool builds a new PCM16 WAV from the selected frames only — the start frame is included and the end frame is excluded.
- Preview the cut result on the page and listen for the spoken words or musical transient at both boundaries.
- Download the WAV. A fresh blob URL is created for the download; changing either time field clears the previous WAV, and picking another file releases the old buffer, players, and result.
For a slightly broader walk-through that covers related decisions like previewing and naming your output, the how to cut an audio recording in your browser guide shows the same flow in more detail.
What Stays on Your Device During the Cut
Because no bytes leave the browser, you can audit what "local" actually means. The source file is read into a File object that the page references by URL; the decoded PCM lives in a JavaScript AudioBuffer (see MDN AudioBuffer) until you replace it or close the page. The exported WAV is a freshly encoded PCM16 file held in another in-memory blob, and a temporary object URL points the download button at it. The page closes the underlying AudioContext after decoding and during cleanup, and it guards in-flight reads so an older job cannot overwrite a newer selection. URLs are revoked when a file or result is replaced, so the temporary handles do not linger.
What this means in practice is that nothing of yours is written to a server, no conversion job is queued, and there is no third-party transcoder waiting to receive your audio. If you keep your laptop, your browser profile, and your hard drive private, the cut stays private. The one caveat is that your browser itself must decode the format; if the codec is unsupported, the tool produces a clear decode error rather than silently sending the file somewhere else.
Limits That Keep Local Cutting Predictable
Because the tool holds the decoded buffer in memory and refuses to silently fail, it publishes explicit ceilings. An over-limit file is rejected with a message rather than partially processed.
| Constraint | Limit | What it applies to |
|---|---|---|
| Encoded input file size | 25 MB | The original file before decoding |
| Decoded duration | 15 minutes | The full AudioBuffer length |
| Decoded sample rate | 192 kHz | The AudioBuffer rate after any Web Audio resampling |
| Channel count | 8 | The number of channels in the decoded buffer |
| Total samples | 30,000,000 | Frames × channels summed across the whole file |
| Selection size | At least 1 frame | A cut that rounds to zero frames is rejected |
The 30-million-sample cap is what really matters for high-rate or multichannel material: a stereo 192 kHz source can hit the cap before it hits the 15-minute duration cap. If your source is over any of those limits, the tool will say so rather than trim partway or upload anything. The exported WAV is uncompressed, so its body is selected frames × channels × 2 bytes plus a 44-byte RIFF header — which is why short clips are the comfortable sweet spot for browser-based cutting.
When an Audio Cutter Does Send Files to a Server
It helps to know the warning signs so you can tell local tools apart from upload-based ones. A server-side cutter typically shows progress percentages tied to a remote job, requires you to wait for an email or refresh, lets you share the result by sending someone a link, or offers output formats that depend on a server-side encoder such as MP3 or AAC. It may also advertise batch processing for many files at once. None of those features are inherently bad, but each one implies that the audio bytes have crossed the network.
By contrast, a strictly local cutter never asks you to wait for a remote job, never emails you a link, and produces an output you could in principle build yourself from the same in-memory buffer. The Audio Cutter falls into that second category: it does not install a codec, does not call a conversion server, and does not silently substitute another source. The download you receive was assembled frame by frame from the audio buffer your browser decoded from the file you picked — and that file never left the tab. If a future project does need server-side features like batch transcoding or metadata preservation, plan on using a dedicated editor alongside, rather than expecting a privacy-first browser tool to expand into those roles.