How to build a browser video editor with Replit

Rule of thumb: if your users are editing their own short clips (a minute or two, on ordinary hardware) the browser handles it and you never see a compute bill, which makes owning the editor the obvious call. If your product processes long or high-resolution files, or has to render hundreds of videos without anyone present, rent the rendering, because a laptop tab is the wrong machine for that job. The middle case is a product that mostly does short clips and occasionally does not, and the honest answer there is to build the editor and set a file-size ceiling you are comfortable defending.

* What you store is source files people chose to keep and the exports they made, so the number depends entirely on whether you keep either. Supabase Free includes 1 GB of file storage and 5 GB of egress a month. Pro, from $25/mo, includes 100 GB of storage and 250 GB of egress, then charges $0.0213 per GB stored and $0.09 per GB served. Deleting an export a week after it was downloaded is the single cheapest decision available here, and it belongs in your retention rule rather than in a bigger plan.

Whichever column you pick, the running cost afterwards is storage and hosting rather than compute, and it stays that way whether ten people or ten thousand are exporting, because every one of them brings their own processor to the job.

Prices and rates from supabase.com, developex.com and replit.com, checked August 2026.

The first two are all you need to start. Everything here stays inside the one browser tab, the app included once you publish it, and the GitHub copy is the one deliberate exception.

1. 01

   Start the app, ask for the database, and set the rule

   The database comes free with the workspace, so it goes in the opening message. So does the constraint that matters most on this build.

   PromptSet up the project and the databaseCopy

   Set up a React 18 + Vite + TypeScript app with Tailwind, and add a Postgres database to this Repl, the one Replit provisions, not anything outside. Write a short notes file at the project root saying this is a browser video editor, fixing the vocabulary as projects, videos, clips, and exports, and recording one standing rule: all video processing happens in the visitor’s browser through FFmpeg compiled to WebAssembly, and no server-side transcoding should ever be added. Keep the database connection details in Replit's Secrets rather than in the code.

   The rule is worth writing into the notes file rather than a single message. Adding a server-side transcode is a natural suggestion for any assistant, and it would put back the cost this build exists to avoid.

2. 02

   Prove the encoder in the live preview

   One throwaway page, one trimmed file. Do it before anything depends on it, and roll back to a checkpoint if it goes sideways rather than unpicking it.

   PromptGet FFmpeg running in the browserCopy

   Add @ffmpeg/ffmpeg and @ffmpeg/util and build a single page that proves in-browser encoding works: pick a local video file, enter a start and an end time, press a button, and get the trimmed file back as a download. Use the single-threaded @ffmpeg/core loaded through toBlobURL so the CDN assets are not blocked by CORS, and show the real progress events rather than a spinner. Then tell me how it behaves on a large file in the preview.

   Check this in the live preview rather than trusting the description. In-browser encoding is exactly the kind of thing that looks fine in code and behaves differently in a real tab.

3. 03

   Build the timeline

   The screen that carries the product. Check the preview after each change here rather than stacking several and finding out which one broke the playhead.

   PromptBuild the timelineCopy

   Build the editor screen: a horizontal timeline of clips end to end, each draggable to reorder and trimmable from both edges, with a playhead, a ruler in seconds, and a preview above that follows the playhead while scrubbing. Drive all of it from one piece of timeline state so a clip’s in-point, out-point, and position can never disagree with what is displayed. Placeholder clips are fine for now.

   This is the step where checkpoints earn their keep. A timeline that felt right two messages ago and does not now is a one-click problem rather than an afternoon.

4. 04

   Add sign-in and scope every row to its owner

   Replit’s Postgres is a plain database with no login wired into it, so the Agent writes both halves: sessions on the server, and policies the server’s identity feeds.

   PromptAdd sign-in, roles, and access rulesCopy

   Add email-and-password sign-up, login, logout, and a server-side session, with a profile row per account. Then the tables: projects owned by one account, videos belonging to a project, and exports recording each finished render with its settings and output length. Add a roles table giving each account one of visitor, user, or admin, in its own table, never on the account record, since anything there is editable by that user. Then turn on row-level security across all three tables: have the server set the current account and role as a session-local setting at the start of every request, and write the policies to read it, so a person reaches only their own rows and an admin reaches everything. Show me how to prove a second account comes back empty before we move on.

   There is no ready-made login handing the database a user id here, so the server is what knows who is asking. Build that first and the policies have something to read.

5. 05

   Wire the export and the dashboard

   Connect the timeline to the encoder, then give people somewhere to find what they made.

   PromptBuild the export flow and dashboardCopy

   Connect the timeline to the encoder. Export should turn the timeline state (the trims, the clip order, and the chosen aspect ratio) into a real ffmpeg run in the browser, report honest progress, and return a finished file, with widescreen, vertical, and square offered as presets. Record each completed export in the exports table, and generate a thumbnail per clip locally. Then build the project dashboard: the signed-in person’s projects with thumbnails and last-edited times, actions to open, rename, duplicate, and delete, and each project’s previous exports listed alongside it.

6. 06
   Destination

   Add demo mode and admin, then publish

   Finish with the two pieces that sell it and keep it healthy, then publish, checking who the app is visible to before that first release, since Publishing is what sets it.

   PromptAdd demo mode, admin, and publishCopy

   Add the last two pieces. Demo mode: a signed-out visitor gets a throwaway workspace with a sample clip, backed by its own demo tables so nothing they do reaches real data. And an admin view covering storage used, exports run, and accounts, restricted to the admin role. Then help me test the whole flow: open the demo signed out and cut the sample, sign up, load a real video, trim and reorder it, export vertically, and confirm the export appears in the dashboard and the admin view. When it holds up, walk me through Publishing: which deployment type fits an app whose heavy work happens in the visitor’s browser, and who the app should be visible to.

Review the access rules (row-level security policies) on every table. For each one, tell me in simple terms who can view, add, edit, and delete records, confirm that people can only reach their own data while the right roles can reach more, and flag anything left open that shouldn’t be.

The one rule that matters: the database connection, and any AI provider key you add later, never go into the app or a public repo. If one gets out, treat it as compromised and rotate it the same day.

All four are Replit rather than a third party, so the choice is shape rather than vendor, and Autoscale suits most of these apps. One thing to raise with the Agent before you publish: the faster multithreaded encoder needs the page to be cross-origin isolated, which means specific response headers on whatever serves it. The single-threaded default this guide builds on needs none of that, so treat it as a later optimisation and check what your deployment can send before you commit to it. Either way, review who the app is visible to before that first release.

Add a "Generate captions" action on the editor that extracts the audio track from the current cut, sends it to a server-side function that calls a speech-to-text model, and returns timed segments. Render them as an editable caption track on the timeline that the user can fix before burning them into an export, and keep the audio out of long-term storage once the transcript comes back.

Add a "Tighten this" action that analyses the transcript and the audio levels for long pauses, filler, and dead air, then proposes a set of cuts as a preview the user accepts, adjusts, or rejects on the timeline. Never apply them automatically, and always leave the original clip intact so the change can be undone.

Add a panel on the export screen that sends the transcript to your ai function and returns a suggested title, a short description, and a handful of tags, sized for wherever the user says they are publishing. Present them as editable drafts rather than final copy, and let the user regenerate any one of them on its own.

Add a "Suggest a thumbnail" action that pulls several candidate frames from the finished cut (avoiding blur, blank frames, and mid-blink shots) and offers them as a row the user picks from, with the option to scrub for their own frame instead. Generate the candidates on the device using the frames you already have, so no video leaves the browser for this.

A cheap model is plenty for most of the prompts above. Save Pro’s stronger models for the one or two spots where the extra reasoning actually pays for itself. Add any provider key through Replit’s own Secrets tool rather than hard-coding it, and keep every AI feature behind one server-side function so a single key covers the whole app.