I kept running into the same problem: I needed to make a video smaller, trim a clip, or extract its audio, but many online tools introduced another problem first.
They asked me to create an account, added a watermark, or required uploading a private media file to an unknown server.
So I built Video Compress Kit: a free collection of browser-based video, image, and audio tools. There is no sign-up, no watermark, and media processing happens on the user's device.
The idea behind the project is simple:
Free. Simple. Yours.
What Video Compress Kit does
The first release includes six focused tools:
- A video compressor with quality and resolution controls
- An image compressor for common web image formats
- An audio compressor with MP3 as the default output
- A video trimmer for removing unwanted beginnings and endings
- A video cropper and resizer for changing dimensions and aspect ratios
- A video-to-audio extractor for MP3, M4A, AAC, OGG, WAV, FLAC, and WebM audio
The interface is available in English and Japanese. Files can be selected from the device, and a public direct media URL can also be imported when the source allows browser access.
Each tool has its own workflow and explanation. I did not want one generic converter page with a different heading pasted on top. A person trimming a video has different questions from someone compressing an image, so the surrounding guidance, examples, and controls should reflect that task.
Why process media in the browser?
My main product decision was to keep media files on the user's device.
With the usual cloud workflow, a user has to upload a large file, wait for server processing, and download the result. That creates three sources of friction:
- Upload time can be longer than the actual processing time.
- Private or client media leaves the device.
- Server costs eventually push a supposedly free tool toward queues, credits, or file-size paywalls.
Video Compress Kit downloads the application code, then processes the selected media locally. Cloudflare serves the website, but the media file itself is not uploaded to the Video Compress Kit server.
That makes the privacy promise concrete: the video stays in the browser tab where the user selected it.
Building it with Mediabunny
The media layer uses Mediabunny, a JavaScript media toolkit designed around modern browser APIs.
It provides a cleaner way to inspect tracks, decode media, transform video and audio, and write output containers without building the product around a large command-line program compiled to WebAssembly.
The rest of the application uses React 19 and TanStack Start. It is deployed on Cloudflare Workers, while the tool interface is built from reusable shadcn/ui components.
At a high level, the processing path looks like this:
Select a local file or import a public URL
↓
Inspect media tracks
↓
Apply the selected tool settings
↓
Encode the result in the browser
↓
Download the output
I lazy-load optional MP3 and FLAC encoders so people only download those components when they need them. The application also avoids silently returning a video without its audio track when the browser cannot encode the requested combination.
Local processing has real trade-offs
Running everything locally is not a magic performance trick. It moves the work from a remote server to the user's device.
That means processing speed depends on the browser, codec support, hardware, file length, and selected output settings. A recent desktop browser will usually have a better experience than an older phone processing a long 4K recording.
The current web tools accept one file at a time, up to 500 MB. I chose that boundary because a clear limit is better than promising unlimited processing and letting a browser tab run out of memory without explanation.
Format support also depends partly on the browser. When an encoder is unavailable, the interface should explain the limitation rather than pretend every format works everywhere.
These constraints are part of the product design, not details to hide in a footer.
Designing for people who just need the file fixed
Media settings can become technical very quickly. Bitrate, codecs, containers, frame rates, and sample rates are useful, but most people arrive with a simpler goal:
- Make this video small enough to share
- Remove the first few seconds
- Turn this video into an MP3
- Resize a clip for a different screen
The interface starts with presets and plain language, then exposes more control where it is useful. It also shows the original and output file sizes after processing so the result is understandable immediately.
There is no login wall before the download. A tool that promises a quick result should not reveal an account requirement only after the user has waited for processing.
What I learned
Three lessons have shaped the project so far.
1. Privacy works best as architecture
A privacy sentence is stronger when the system does not need the file in the first place. Local processing reduces what the service has to collect and protect.
2. A focused tool needs focused content
Duplicating the same marketing copy across every tool is easy, but it is not helpful. Each page should answer the questions that belong to its actual task.
3. Honest limits improve the experience
Browser media APIs are improving quickly, but compatibility and device performance still vary. Clear errors and realistic limits are more useful than a long list of formats that has not been tested.
What is next?
I am currently exploring a video frame extractor for saving a precise frame or exporting images at selected intervals. I also want to improve compatibility, add more practical presets, and use real user feedback to decide which workflows deserve their own tools.
If you regularly compress, trim, crop, or convert media, you can try Video Compress Kit.
I would especially like to know:
- Which browser and device did you use?
- Which format worked or failed?
- What media task still takes too many steps?
That feedback will shape the next release.
Top comments (0)