What happens to your recording if the browser crashes

If your browser crashes mid-recording, Orec recovers the session automatically when you reopen the page. You lose at most the last 3 seconds of audio. The rest is sitting in your browser's local storage, ready to reassemble.

Most browser recorders don't work this way. They hold your audio in RAM until you hit stop. Close the tab by accident, and the recording is gone. Orec writes to disk continuously, so the stop button is mostly ceremonial.

How continuous saving works

The recorder calls MediaRecorder.start(3000), which fires a data chunk every 3 seconds. Each chunk goes straight to an IndexedDB transaction before the next chunk starts arriving. IndexedDB is the browser's built-in key-value store: it persists across reloads, requires no server, and Chrome allows at least 60% of available disk space per origin. On a 256 GB laptop that's over 100 GB of headroom.

The flow during a session:

1. Microphone audio flows into MediaRecorder
2. Every 3 seconds, a blob is written to IndexedDB under a session ID and chunk index
3. The in-memory buffer resets
4. On stop, all chunks are read back and decoded into a single WAV

If anything interrupts between steps 2 and 3, you lose at most one chunk: 3 seconds. If the browser crashes after step 2, all prior chunks survive.

Recovery when you reopen the page

On load, the recorder checks for an orphaned session ID in localStorage. If chunks exist for that session, it offers to recover. Accepting replays all the saved chunks, stitches them into a WAV, and drops you into the editor as if you'd stopped normally.

If you'd rather just start fresh, discarding the recovery deletes the orphaned chunks and clears the session. No data lingers.

The chunk stitching matters for audio quality. WebM/Ogg containers can be concatenated directly. For Safari's MP4 container, the code decodes each chunk individually and concatenates the PCM buffers before re-encoding to WAV. Either way, the reassembled audio plays back without audible seams.

Why IndexedDB and not the File System Access API

The File System Access API lets browsers write directly to a file on disk, which sounds ideal. The problem is it requires an explicit permission prompt every session, and Safari's support has historically been inconsistent.

IndexedDB needs no permission beyond the initial microphone grant, works in every modern browser, and stores blobs natively without serialization overhead. For a tool whose job is to stay out of your way, it's the right choice.

If you want to understand the WAV format the recorder produces, read about which audio format to export. For tips on getting the best quality out of your microphone before you hit record, see the guide on recording high-quality audio in the browser. You can also confirm your mic is working correctly with the mic test tool before starting a long session.

After you've got a clean take, the audio trimmer can remove any silence at the start or end, and you can share the recording with a link without a file attachment.