Why Breaking News Maker renders in your browser

Most tools that turn your media into video work the same way: you upload your photo or clip to a server, a render farm composites the result, and you wait in a queue to download it. Breaking News Maker does none of that. The MP4 you export is drawn and encoded on your own machine, by your own browser. That one decision shapes everything else about the product — so it's worth explaining.

The privacy argument

Think about what actually goes into a breaking-news meme: a photo of your friend's face, a clip from your camera roll, a headline with their name in it. It's personal media attached to a fabricated news graphic. The last place that combination should live is a stranger's server, tied to your account, retained under a policy you didn't read.

With client-side rendering there's nothing to retain. Your backdrop photo is read locally and drawn onto a canvas. Your headline exists in your tab. The finished video is encoded on your device and downloads straight from the browser. We never receive your media or your headlines — not "we delete them promptly," but they never arrive. Privacy by architecture instead of by promise. Our privacy policy is short mostly because there's so little to disclose.

How it works

Every frame of the broadcast — the backdrop with its slow push-in, the typewriter headline mid-reveal, the ticker at its current scroll offset, the pulsing LIVE badge, the clock — is drawn to a canvas, 60 times per second of output. For years, turning canvas frames into real video in a browser meant either screen-recording the canvas (dropped frames, wrong timestamps) or shipping a giant WebAssembly encoder.

The WebCodecs API changed that. Browsers now expose the same hardware video encoders native apps use, so we feed frames straight to the encoder and mux a real MP4 (with a WebM fallback for browsers that need it). The intro sting is synthesized with the Web Audio API — original audio, no sampled network jingles — and mixed into the audio track at the exact frame the broadcast starts.

An 8-second, 60fps video is 480 frames. On a modern laptop or phone that encodes in a few seconds — usually faster than a server-side tool would have finished uploading your backdrop clip.

The economics are your economics

Server rendering costs money per export. That cost is why competitors watermark aggressively, sell "render minutes," and make you wait in queues that prioritize paying users. Our marginal cost per export is zero — your hardware does the work — so the free plan's limits exist to keep accounts honest, not to recoup compute. It's also why Pro can be $4.99 instead of $15: you're paying for features, not for our GPU bill.

What you see is what you export

One renderer draws both the live preview and the exported file. There's no "preview approximation" that gets re-rendered differently on a server — the editor is the renderer, running at full speed while you type. When the typewriter reveal looks right in preview, it's right in the file.

The honest trade-offs

Depending on your browser means depending on your browser. You'll want a recent Chrome, Edge or Safari and hardware from the last several years. Very old machines encode slowly, and some browsers get the WebM fallback instead of MP4. We think the trade is obviously worth it: instant exports, zero uploads, and a tool that stays fast no matter how many people are using it — there's no queue to be at the back of.

The same philosophy runs our sibling product Chatimator, which renders fake text-message videos the same way. Once you build one product where user content never touches your servers, it's hard to justify building the next one any other way.

Open the editor and watch an export finish before an upload bar would have reached halfway.