Audio, subtitles, and metadata are not all preserved when Video Compressor re-encodes a file: the tool only carries across the picture and any audio track the current browser exposes through HTMLMediaElement captureStream, because it draws frames into a Canvas and records a fresh WebM rather than repackaging the source container. Subtitles — soft text tracks, sidecar files, and embedded captions — are never read or embedded into the output, and chapters, attachments, rotation tags, color metadata, and HDR signaling are stripped along with the original container's features. Hardcoded (burned-in) subtitles survive as part of the picture because the Canvas renders every visible pixel, but only at the preset's frame cadence. Audio is the only one of the three concerns in your question that may carry through, and even that depends on whether the current browser exposes a capturable track for the source codec. Anything you need to keep across the operation should be exported separately, and the downloaded file should be played end to end in the destination's player before you delete the original.
What Video Compressor Captures From Your Source
Video Compressor is built around two browser primitives: a Canvas and a MediaRecorder. When you choose a file and start compression, the page loads the source as a local media element, draws every displayed frame into a bounded Canvas at the preset's cadence, and records the Canvas stream with whichever WebM MIME the current browser reports as supported. Because the output is a fresh recording of frames the browser has just rendered, the file you download is not a repackaged copy of your original — it is a new WebM that contains only what the Canvas pipeline could capture.
That pipeline captures two things well: the picture being drawn at the preset width and frame rate, and any audio track the browser exposes through HTMLMediaElement captureStream. Everything else lives in metadata, side files, or container features that the re-encoding step never reads, so they cannot be carried into the WebM container. This is a property of the re-encoding approach rather than a bug to work around; if you need to keep container features intact, the right tool is one that copies or remuxes the original stream rather than re-encoding it.
Audio: When It Carries Through to the Output
Audio is the only one of the three concerns in your question that may survive a Video Compressor run, and even that is conditional. The implementation appends a capturable audio track to the recorded stream only when the browser exposes an audio track through HTMLMediaElement captureStream. Different browsers expose different tracks for different source codecs, so the same source can produce a WebM with sound on one browser and a silent WebM on another, even with the same preset.
Two practical consequences follow. First, the source plays audibly while compression runs in real time, so device volume matters — but muting the page does not necessarily detach the captured track, and you should not assume an inaudible preview means a silent output. Second, play the downloaded file end to end before deleting the original. The page does not normalize volume, mix tracks, remove hiss, or verify which audio codec the recorder chose, so the only authoritative answer for your specific run is the file itself.
For sources whose audio is in a format the current browser cannot expose through element captureStream, the output WebM will be silent regardless of the picture preset you choose. If silent output is unacceptable for your destination, check the file in a player that exposes track information before deleting the original.
Subtitles, Captions, and Text Tracks
Subtitles are not preserved by Video Compressor. The tool does not read caption tracks, sidecar files, or any soft text the source carries in its container, and the WebM produced by MediaRecorder does not embed them in the output. If your video has hardcoded subtitles — text drawn into the actual pixels — they will appear in the output because the Canvas renders every visible frame, but only at the preset's frame cadence, so motion smoothness around text edges depends on which preset you choose.
If your video has soft subtitles stored as a separate track inside an MP4 or MKV, or as a sibling .srt or .vtt file, those files are untouched by the compressor and will not be merged into the WebM. There is no setting inside Video Compressor that retains them, because the re-encoding approach reads the picture and any exposed audio track and writes a fresh WebM that contains only what those two sources provided.
For any workflow where subtitles need to travel with the video, you need a tool that explicitly preserves text tracks, such as a maintained desktop encoder with a reviewed command that copies the text stream or transcribes it into the output container. The same applies to chapters, attachments, and any other side data that lives outside the picture — none of which the browser-based pipeline reads.
Metadata, Chapters, Attachments, and Container Features
Video Compressor strips container-level metadata. The product contract lists what is not preserved by name: subtitles, chapters, attachments, rotation tags, color metadata, and HDR signaling. None of these are read from the source or written into the output WebM, regardless of preset.
Because the output container is fixed to WebM, the original container's features do not transfer even when those features exist in the source. A portrait-orientation MP4 with a rotation tag, for example, will not carry that tag into the WebM, and the picture itself will appear in the orientation the Canvas rendered it — which may look sideways if the source relied on the tag rather than on baked-in pixels. Color primaries, transfer characteristics, and HDR metadata are similarly dropped, so an HDR source becomes a standard-dynamic-range WebM at the preset's resolution.
The table below summarizes what survives the pipeline and what does not. Where the row says conditional, the answer depends on the browser and the source codec rather than on a setting inside the tool.
| Source element | Survives compression? | What actually happens |
|---|---|---|
| Picture (visible pixels) | Yes | Re-encoded into WebM at the preset width, capped frame rate, and bounded bitrate |
| Audio (browser-exposed track) | Conditional | Appended only when the current browser exposes a capturable track via HTMLMediaElement |
| Soft subtitles / caption tracks | No | Not read, not embedded; sibling .srt and .vtt files remain untouched |
| Hardcoded (burned-in) subtitles | Yes | Visible because the Canvas renders every pixel; smoothness depends on preset cadence |
| Chapters | No | Not read from the source, not written into WebM |
| Attachments, fonts, side images | No | Not read from the source, not written into WebM |
| Rotation tag | No | Not copied; picture renders in decoded orientation |
| Color metadata / HDR signaling | No | Dropped; output is standard dynamic range |
| Original filename, container, codec | No | Output is always a new WebM produced by MediaRecorder |
How to Compress a Video and Check What Survived
The fastest way to confirm whether your specific run kept what you cared about is to play the downloaded WebM in the same player your destination uses, end to end, before deleting the original. The steps below cover the full path from file selection to verification.
- Pick a browser-decodable source no larger than 500 MiB, no longer than five minutes, and no more than 3840 × 2160 pixels of decoded area with no side above 4096 pixels. Files may be named MP4, WebM, MOV, M4V, or Ogg, but the extension only helps the browser pick a starting point — successful decoding depends on the current browser's installed codecs.
- Open the Video Compressor page and choose the file from your device. The tool reads the file locally; nothing is uploaded.
- Select Small (640 px wide, 24 fps), Balanced (1280 px wide, 30 fps), or Quality (1920 px wide, 30 fps). Each preset keeps the source aspect ratio, never enlarges, and rounds dimensions down to even pixel values. Pick the preset that matches the destination's constraints rather than the smallest possible number.
- Start compression. Keep the tab open while the source plays in real time — the MediaRecorder observes the Canvas stream, so a two-minute source takes roughly two minutes. The source plays audibly when it contains audio.
- When the source ends, the tool reports output dimensions, input bytes, output bytes, and the signed percentage change calculated only from the two actual Blob sizes.
- Download the WebM and play the whole file before deleting the original. Confirm the picture matches what you expected, sound is present if the source did, and the duration plays to the end in the player where you intend to use it.
- If the picture looks wrong, the sound is missing, or the size change is not what you expected, try a different preset or work through the common failure modes for local video compression before re-running.
Input Limits That Decide Whether Encoding Starts
Some sources cannot be compressed at all, regardless of which track the browser exposes. Video Compressor validates the file before starting: extension or MIME must be recognized, byte size must be a positive number up to 500 MiB, decoded duration must be above zero and at most 300 seconds, each side must be at most 4096 pixels, and decoded area must not exceed 3840 × 2160. Any failure here produces an error and no download — the tool never silently truncates or re-encodes a partial file.
These limits exist to bound memory, Canvas allocation, and the real-time work the encoder performs. A two-minute source at 1920 × 1080 produces roughly 30 fps × 120 seconds = 3,600 frames drawn at the Quality preset's cadence; pushing the duration or resolution higher would outgrow what a browser tab can keep up with while the MediaRecorder is observing. If your source exceeds them, the page refuses to start and you need a different tool.
The table below lists every limit that decides whether the pipeline runs, including the preset caps on width and frame rate and the bounded bitrate range the recorder chooses from.
| Limit | Value | What it bounds |
|---|---|---|
| File size | 500 MiB | Memory and the Blob round-trip |
| Duration | 300 seconds (5 min) | Real-time MediaRecorder workload |
| Side length | 4096 px max each | Canvas allocation and decode memory |
| Decoded area | 3840 × 2160 max | Per-frame pixel work |
| Container | Browser-decodable | Whether HTMLVideoElement will load the file |
| Output container | WebM (VP9 → VP8 → generic) | MediaRecorder codec availability |
| Output width cap | 640 / 1280 / 1920 px | Small / Balanced / Quality |
| Output frame rate cap | 24 / 30 / 30 fps | Small / Balanced / Quality |
| Output bitrate | 180 kbps – 8 Mbps | Bounded bits-per-pixel heuristic |
When You Need Full Preservation Instead
Video Compressor is the right tool when you want to shrink a video for a destination that accepts WebM and you do not need to keep subtitles, chapters, attachments, rotation tags, color metadata, or HDR signaling. It is the wrong tool when any of those features have to travel with the file.
For archival masters, professional delivery specifications, exact codec profiles, two-pass rate control, fixed keyframe intervals, subtitle preservation, or deterministic cross-platform output, the product contract points to a maintained desktop encoder such as FFmpeg with a reviewed command. FFmpeg and similar tools can remux streams without re-encoding — keeping codecs and side data intact — or transcode with explicit flags for subtitles, chapters, color, and rotation. None of those guarantees are available through a browser-based Canvas approach, because the Canvas only sees pixels.
If you only need to know whether the file you just downloaded kept what you cared about, play it back in the player where it will be used. The percentage shown by Video Compressor is calculated only from the two actual Blob sizes; it does not promise every result is smaller, and it does not promise any track was kept. The downloaded file is the only authoritative answer for your specific source and your specific browser. Keep the original until you have played the complete output and confirmed that size, duration, picture, sound, and compatibility meet the destination's requirements.