Hi everyone!
I’ve been building a side project called Vidoro — a collection of simple online media tools focused on video compression, format conversion, privacy, and practical everyday workflows.
The idea is straightforward:
Choose a file → process it → download the result.
No complicated editing interface, no unnecessary account creation, and for tools that can reasonably run in the browser, no file upload to a remote server.
Vidoro currently includes a homepage, two versions of the video compressor, and a MOV-to-MP3 converter. I’m gradually turning it into a larger collection of focused media utilities.
💡 Why I Built It
A lot of online media tools technically work, but the experience often feels heavier than the task itself.
For something as simple as reducing the size of a video or extracting audio, users may have to:
upload a large file to a remote server
wait for the upload to finish before processing even starts
create an account
navigate several configuration screens
deal with watermarks or usage restrictions
wonder what happens to the uploaded file afterward
I wanted Vidoro to feel more like a local utility that happens to run in a browser.
Whenever browser-side processing makes sense, the file stays on the user’s device and FFmpeg runs through WebAssembly.
For heavier or smarter workflows, Vidoro can also use a backend processing pipeline, but I try to keep that distinction clear to the user.
🌐 Vidoro Homepage
The homepage is the central entry point for the project.
Instead of building every tool as an isolated website, I’m putting them under one product and one design system.
The goal is for Vidoro to eventually become a toolbox for common media tasks such as:
video compression
audio extraction
video conversion
image conversion
video-to-GIF
audio processing
other lightweight media utilities
The homepage is intentionally simple.
Rather than showing dozens of settings or categories immediately, it introduces the available tools and lets users go directly to the task they need.
🎬 Compress Video Online — English
👉 https://vidoro.io/compress-video-online/
This is the English, privacy-focused version of Vidoro’s video compressor.
The main idea behind this page is:
compress the video directly in the browser without uploading it to a server.
The workflow is:
Choose a video
Select a compression level
Let FFmpeg WASM process the video locally
Download the compressed MP4
The current compression options are intentionally simple:
High Quality
Balanced
Maximum Compression
I didn’t want users to have to understand CRF values, encoding presets, audio bitrates, or other FFmpeg parameters just to reduce a file size.
Under the hood, the browser version currently uses FFmpeg with H.264 video and AAC audio and generates an MP4 output.
The page supports common formats such as MP4, MOV, AVI, MKV, WebM and other formats already handled by the converter.
One of the main goals of this version is privacy.
For the normal compression workflow:
the video stays on the device
there is no server upload
there is no account requirement
there is no watermark
This also means the performance depends heavily on the user’s device.
A powerful desktop can process videos reasonably well, while very large files on a phone can obviously be more challenging.
That tradeoff is something I’ve found interesting while building the project.
🇧🇷 Comprimir Vídeo Online — Portuguese
👉 https://vidoro.io/pt/comprimir-video-online/
The Portuguese version is currently more advanced than the English version.
It contains the same local FFmpeg WASM compression workflow, but it also includes a smart compression mode.
This mode is aimed at a problem I noticed while working on video compression:
Most users don’t actually know what compression settings they need.
They don’t think in terms of:
bitrate
codec
CRF
frame rate
resolution
They think in terms of:
“I need to send this on WhatsApp.”
or
“I need a smaller attachment for email.”
or
“I want to save storage space.”
So the smart compression mode analyzes information about the uploaded video and allows the user to choose a target use case such as:
WhatsApp
Instagram
Email
Website upload
Storage saving
Vidoro then recommends a compression profile.
The analysis can include information such as:
resolution
duration
codec
FPS
file size
bitrate where available
The system then recommends settings such as:
target codec
CRF
target resolution
FPS
estimated output size
I also spent some time improving the output-size estimation.
An early version could predict something like:
4.7 MB → 700 KB
while FFmpeg actually produced something closer to:
4.7 MB → 2.1 MB
That was obviously too optimistic.
The estimation system is now more conservative and takes more properties of the source video into account.
In one of my later tests:
Original: 329,498 bytes
Predicted: 166,045 bytes
Actual output: 159,576 bytes
Reduction: 51.6%
That was much closer to the real output.
🤖 AI / Smart Compression Architecture
One important design choice is that the smart compression system does not require an AI API to work.
It uses a hybrid approach.
The basic pipeline can work with:
ffprobe → video metadata → deterministic compression profiles
So even without an OpenAI API key, it can still analyze the video and generate recommendations.
An optional LLM layer can be used for richer recommendations, but the core functionality does not depend on it.
I like this architecture because I don’t want an “AI feature” to stop working just because an external API is unavailable.
The deterministic system remains the fallback.
🎵 MOV to MP3 Converter
👉 https://vidoro.io/mov-to-mp3-converter/
The MOV-to-MP3 converter is much simpler, and that is intentional.
Its job is just:
take a MOV video and extract the audio as MP3.
The entire conversion happens inside the browser with ffmpeg.wasm.
The MOV file is not uploaded to Vidoro.
The workflow is:
Select or drag in a MOV file
Choose MP3 quality
Convert it locally
Download the MP3
This can be useful for things like:
extracting audio from iPhone videos
interviews
lectures
voice recordings
video podcasts
saved clips
music or audio recordings stored inside MOV files
The default configuration is designed to be simple rather than expose every FFmpeg audio option.
For this kind of task, I think that is the right tradeoff.
Most users don’t want to configure sample rate, channels, codec profiles, and command-line flags.
They just want the audio.
🔒 Why I Like Browser-Side Processing
One of the most interesting parts of building Vidoro has been deciding which jobs belong in the browser and which belong on the server.
For tasks like:
MOV → MP3
normal video compression
simple format conversion
browser-side FFmpeg can work surprisingly well.
There are several benefits.
No upload time
If someone has a 300 MB video, a server-based tool may require the entire 300 MB upload before processing even begins.
With browser processing, work can start locally.
Better privacy
The media file can remain on the user’s machine.
For private recordings, internal work videos, family videos, interviews, or other sensitive material, that is useful.
Lower backend infrastructure requirements
Simple media jobs don’t necessarily need to consume server CPU, storage, queues, and bandwidth.
But there are tradeoffs
WebAssembly processing is not magically faster than native FFmpeg.
Large files can consume a lot of browser memory, and mobile devices can struggle with demanding workloads.
That is why Vidoro also has a server-side architecture for jobs where browser processing is not the right choice.
🧱 The Tech Stack
Vidoro currently uses:
Frontend
Next.js 16
React 19
TypeScript
Tailwind CSS
App Router
Browser Media Processing
FFmpeg
ffmpeg.wasm
WebAssembly
Backend
FastAPI
Celery
Redis
PostgreSQL
Server Media Processing
FFmpeg
ffprobe
Deployment
The frontend is designed to run independently from the backend.
Browser-local tools can work without sending media to the backend at all, while server-assisted features use the FastAPI/Celery pipeline.
⚙️ How the Server Compression Pipeline Works
For server-assisted compression, the architecture is roughly:
Video upload
→ FastAPI
→ storage
→ Celery task
→ FFmpeg
→ compressed result
→ download
Redis handles the task queue, while the backend and Celery worker share the same storage volume.
That last part sounds obvious, but it caused one of the bugs I ran into.
The backend successfully saved a file to:
/app/storage/uploads/...
but the worker had a different container filesystem and saw an empty directory.
The API worked.
The upload worked.
The Celery task started.
Then the worker reported:
Input file missing
The fix was to use a shared Docker volume between the backend and worker.
That was one of those bugs where every individual component looked healthy, but the full workflow still failed.
🧪 Things I Learned
A few lessons from building the project so far:
- Browser FFmpeg is useful, but it has limits
For many everyday jobs, ffmpeg.wasm is genuinely useful.
For very large 4K videos or CPU-heavy transformations, native server-side FFmpeg is still much more capable.
- “AI” works better when it solves a specific problem
I don’t want Vidoro to add a chatbot just because AI is popular.
The useful application here is helping users answer questions like:
What settings should I use?
or:
How do I make this small enough for email?
That is much more practical than adding a generic chat panel.
- Output-size prediction is harder than it looks
You can’t simply say:
output = original × 0.2
Video content, existing bitrate, motion, codec, resolution, and CRF all matter.
A prediction that looks impressive but is consistently wrong is worse than a conservative estimate.
- Privacy can be a product feature
Moving media processing into the browser is not only an implementation detail.
It changes the user experience.
“No upload required” is something users can actually understand.
- Keep the interface simpler than FFmpeg
FFmpeg exposes hundreds of options.
That doesn’t mean an online tool should.
The job of the product is often to hide complexity rather than reproduce a command-line interface in a browser.
🚧 What I’m Working on Next
I’m continuing to expand Vidoro with more focused media tools.
I’m also experimenting with a more intelligent workflow where users can describe what they want instead of choosing technical parameters.
For example:
“Make this video small enough to email.”
or:
“Extract the audio from this MOV.”
or:
“Make this smaller but keep the text readable.”
The long-term idea is that Vidoro can understand the task, choose the appropriate tool, and configure it automatically.
Underneath, the actual media processing can still be handled by deterministic tools like FFmpeg.
The AI layer would help with intent and parameter selection rather than replace the media-processing engine.
🌍 Try Vidoro
Homepage:
English Video Compressor:
👉 https://vidoro.io/compress-video-online/
Portuguese Video Compressor:
👉 https://vidoro.io/pt/comprimir-video-online/
MOV to MP3 Converter:
👉 https://vidoro.io/mov-to-mp3-converter/
I’m still actively improving the project, especially browser performance, compression quality, UX, and the balance between local and server-side processing.
I’d love feedback on:
the browser-first approach
ffmpeg.wasm performance
the compression workflow
privacy positioning
the smart compression idea
mobile usability
which media tool would be useful to build next
Top comments (0)