How to build a browser video editor with Lovable
Build a working video editor in a browser tab, prompt by prompt. Clips on a timeline people trim and reorder, reframing for vertical and square, and an export that runs on their own machine, with Lovable designing the tables and the access rules in the same chat that builds the editor.
Lovable
$ Build a video editor that runs in the browser: a timeline where people trim and reorder clips, presets for vertical and square, and an export that happens on their own machine. Save projects per account so nobody sees anyone else’s work.
- Encoder running in the preview
- Timeline and projects built
- Ready to preview
Overview & core architecture
A browser video editor is a full editing workspace that opens in a tab: clips on a timeline, a preview that scrubs, and an export at the end, with the cutting and encoding done by the visitor’s own computer rather than by a server you rent.
The familiar version of this is a service: someone uploads footage, a machine somewhere re-encodes it, and a finished file comes back. That works, and it costs money on every single minute of video that passes through. It also means your users hand their raw footage to a third party, which for some of them is the end of the conversation.
The other version builds the video processing into the page itself, so it runs inside the browser tab. The file is opened from the visitor’s disk, cut on their processor, and written back to their downloads folder. Your server never sees it, and never bills you for it. What you build instead is everything around that: the timeline, the projects, the library, and the export queue.
The editing workspace is your primary client feature
Non-technical users judge the experience instantly based on a clean, responsive interface that lets them preview and trim assets without installing complex software.
No raw footage to leak, no render servers to hack
The video is cut on the visitor’s own machine, so nothing is uploaded unless you choose to store it, and your servers never hold anyone’s raw footage. The security section below covers how your editor stays secure and how to protect sensitive client footage.
Decide your file-size ceiling early
Everything runs on the visitor’s own computer, so very long or very high-resolution files are where it strains. Decide the largest file you accept and say so in the interface before launch. It is the first of the six decisions further down.
Essential editor components
Six building blocks make up the editor, and the timeline is the one visitors judge first. Each is something you can ask your AI coding tool to build or rework in plain words.
Drag-and-drop editing timeline
Clips laid end to end, draggable to reorder, trimmable from either edge, with a playhead and a preview that never disagree with each other. This is the hard one, and it is worth building first: if the interaction is wrong, nothing built on top of it will feel right.
In-browser video processing
Professional-grade video processing runs entirely within the browser tab, doing the actual cutting and re-encoding directly on the visitor’s machine. It loads once, works on files picked from their disk, and hands back a finished file, with no upload, no queue, and no per-minute bill.
Media library & saved projects
Media a person has added, the cut they are working on, and the exports they have already made. Without this the editor is a toy: people expect to close a tab and come back to their work.
Vertical, square & widescreen presets
The same cut wanted vertical for one platform, square for another, and widescreen for a third. Doing it as a defined set of output formats rather than a free-form crop keeps both the interface and the export queue simple.
Reliable export with live progress
Real progress rather than a spinner, a warning when a file is big enough to be slow, and something sensible when a tab runs out of memory. Export is where a browser editor either feels solid or feels like a trick.
No-signup demo workspace
An editor is the rare product people can evaluate in thirty seconds, and asking for an account first throws that away. A throwaway demo workspace with a sample clip converts far better than a screenshot.
Own the editor or pay by the minute
Almost everything you could buy here runs video through somebody else’s machines and prices it by the rendered minute. That is the number worth holding on to while you read this table, because processing in the browser removes it rather than reducing it.
Build your own
An editor you own is a one-time build with no compute bill behind it (the visitor’s own processor does the work) and with an AI coding tool writing the plumbing, that build is weeks rather than quarters.
- No per-minute rendering cost, at any volume, because there is no render farm in the loop
- Raw footage never reaches your servers, so it is not yours to store, secure, or explain
- Export presets, aspect ratios, and limits are yours to set rather than a vendor’s to allow
- No watermark you have to pay a tier to remove
- Add your own AI on a model of your choosing: captions, silence trimming, titles
- The code and the records are yours outright, exportable whenever you like
Rent the processing
Shotstack · Cloudinary · IMG.LY · CreatomateRenting gets you rendering that is faster than any laptop and does not care how big the file is. What it costs is a rate on every minute you process, and a dependency in the middle of your product.
- Server rendering is faster than a browser and unbothered by a two-hour 4K source file
- Someone else owns the hard parts: codecs, scaling, and the failures at 3am
- Priced by the rendered minute, the credit, or a licence, so the bill tracks your usage rather than your headcount
- Every minute of video your users make costs you money, including the ones they discard
- Users’ raw footage is uploaded to a third party, which some of them will not accept
- One of the four publishes no price at all, so budgeting means a sales call before you can compare
Rented SaaS platforms charge recurring monthly subscriptions and meter every rendered minute. Owning your code outright eliminates per-seat fees, usage limits, and monthly processing bills.
shotstack.io · checked August 2026
Prices the half a browser editor does not remove: storing the source and delivering the finished file still costs money wherever you keep it. Every plan is priced in credits that cover storage, delivery and processing interchangeably. Useful as a sanity check on your own storage bill even if you never use it.
cloudinary.com · checked August 2026
The closest thing to buying the editor itself rather than the rendering: an SDK you embed in your own product. No figure appears anywhere on the pricing page, and the reason is stated plainly: “Pricing is based on the platforms, components, and AI features you license — not a public per-seat tier”, with “You pay for what you ship. Contact sales for a quote tailored to your usage.” We quote no estimate of the cost, because the vendor publishes none. Evaluating it is free for a month: “Every license includes a 30-day free trial after you download a trial key, with full access to all features.”
img.ly · checked August 2026
Templated video automation rather than an editor a person drives, and included because plenty of teams reach for it when what they wanted was an editor. The plans are sized by output: Essential covers “200+ videos or 2,000 images” with 5 GB of storage, Growth “1,000+ videos or 10,000 images” with 50 GB, and Beyond “5,000+ videos or 50,000 images” with 500 GB. The page showed us no dollar amounts when we read it, so none is quoted here. Check the current prices there before you compare.
creatomate.com · checked August 2026
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.
Why build with Lovable
Skip complex database engineering. Set clear controls for who can open which projects, and save every project and export automatically without managing server code.
Lovable turns that work into a conversation: describe a screen or a rule in plain language and watch it appear in the live preview, in the same tab:
Prompt
Say what you want to add or change, in plain language.
Watch
The live preview rebuilds in the browser as Lovable writes the code.
Try it
Click through the real app, with real buttons, forms and data rather than a mockup.
Refine
Select what’s off and describe the fix, or ask for what’s next.
None of that requires a computer science background or writing code, and the whole build happens in one browser tab, one request at a time.
Data & backendhandled automatically
Connect your database in a single step, right from the chat. Lovable builds the tables, sets up the logins, writes the server-side functions, and turns on live updates, each one an ordinary request in plain language, not a separate tool to learn.
Click to point instead of describing where
Select any element in the live preview with Lovable’s Select elements tool, and your next message applies to exactly that piece.
Full ownership and complete privacy
The app and the records in it are yours. Every change is saved automatically, and the repository Lovable syncs to GitHub is private on every plan, with no technical setup and not one Git command.
Pay a developer, or do it with AI
The unusual thing about this build is what is missing from the table: no rendering line, because no server touches the video. What is left is the one-time cost of writing it, and a small bill for keeping files somewhere.
Hire a developer
Custom build, from scratch- Developer
- ~$9.3k-$37k
- Supabase (backend)
- Free tier · $25/mo (Pro plan)*
- Hosting
- $0 free tier
- Video processing
- $0 - runs on the visitor’s device
- Build time
- ~185 hrs of their work
~$9.3k-$37k to build, then from $25/mo after launch
Our ~185-hour estimate, costed against the rate survey linked below. Its bands run from $45-$75/hr for North American contractors up through $100-$150+/hr for senior US developers, before the 20-40% an agency adds, which brackets the range at roughly $50/hr and $200/hr. Where those hours actually go is worth knowing: most of them are the timeline, and none of them are anything a screenshot would reveal. Then look at the row above: processing costs nothing per minute at any volume, because it happens on hardware you neither own nor rent.
Build it with Lovable
From scratch, with Lovable- Lovable
- Free (30 credits/mo) to $25+/month (Pro, from 100 credits)
- Backend (Supabase)
- Free tier · $25/month (Pro plan)*
- Hosting
- $0 on a Lovable subdomain
- Your time
- ~89 hrs
Free to try the idea, ~$25-$50+/month on Pro while you build a real one, then whichever credit tier you keep using
Lovable bills by credits, so what you pay tracks what you build: importing the pre-built template can fit inside the Free plan’s 30 credits a month, while a full from-scratch build burns through Free fast and usually needs Pro. Pro’s entry rung is $25/month (or $250/year, roughly $21/month effective) for 100 credits, the bottom of a ladder where 200 credits runs $50/month (or $500/year, about $42/month), and a multi-session build often lands on that rung or higher rather than the entry price.
* 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 docs.lovable.dev, checked August 2026.
Decide before you build
Structure your project scope around six essential decision standards.
Maximum file size & length
The single most important number here, and the one nobody sets until it breaks. A browser tab has finite memory, so decide the ceiling (by length, by file size, or both) then say it in the interface before someone picks a file rather than after. A refusal with a reason is a fine experience. A tab that dies at 80% is not.
Input formats & export presets
Deciding you accept MP4 and MOV and produce MP4 in three aspect ratios is a smaller build and a clearer product than accepting anything and offering everything. Write the input list and the output presets down. They shape the editor, the export queue, and half the error messages.
Storage & retention policy
Three separate questions: do you store the source footage at all, do you keep exports after they are downloaded, and how long does an abandoned project live? Storing nothing is a legitimate and very cheap answer. Whatever you pick, build the deletion rather than leaving it to the day the storage bill arrives.
Demo access without an account
An editor sells itself in thirty seconds if you let it. A demo workspace with a sample clip and no sign-up is more work than a screenshot and converts better than one, but it needs its own throwaway data so nothing a stranger does touches your real tables.
Export speed & hosting choice
The default single-threaded encoder is simpler and works everywhere. A multithreaded one is faster but needs specific response headers from your host, which rules some hosting choices out. Decide which matters more before you choose where to deploy, not after.
Sharing & team access
Most editors are strictly private: your projects, nobody else’s. If you want shared team projects or a reviewer link, decide now, because “anyone with the link can watch this export” is an access rule and a storage rule at once, not a toggle you add later.
Comparing your build options
How you start decides how much of this is timeline work versus everything around it. Here is one editor built three ways: by hand, on a UI kit with no notion of a clip, or in Lovable, where the editor and the tables behind it come out of the same conversation.
The timeline is where the weeks go. Dragging a clip edge and having the preview, the playhead, the duration, and every clip after it agree is a week nobody budgets for, and it arrives before you have exported a single file.
A starter kit hands you a dashboard, a settings page, and a file table. It has never heard of a clip, a playhead, or an aspect ratio, so the editor (the only screen anybody came for) starts from nothing.
Describe a screen or a rule and watch the running app change in the same tab, which is unusually useful here, because a timeline is something you judge by dragging it rather than by reading about it.
Estimate your exact build timeframe
Plenty of editors ship without half of this. A tool that only trims and only exports one format is a real product, and a much shorter build. Untick what you are leaving out.
Your estimate
89 hrs
start to finish
Based on the 6 of 6 features you’ve selected, plus ~26h of groundwork. Toggle any on the left to watch the number move, and open the groundwork row to untick what you have already, such as a database that is already running or going live if you are only building a mock-up for now.
A rough estimate, not a quote. Real time depends on how much you customize and how clean your data is.
Let’s set up the tools you need
Nothing gets installed, because the whole workspace is a browser tab. Three things to sort out before step 01, and a fourth worth adding once the project matters to you. After that, you build by describing what you want.
Lovable account
Nothing to download. Sign up with an email, Google, or GitHub account and you land straight in the chat where you describe what to build.
Sign up for LovableLovable subscription
Lovable bills by build credits, so the plan you need follows what you build. Free gives you 5 credits a day, capped at 30 a month, which is enough to try it rather than to finish an app. Pro is $25/month for 100 credits ($250/year, about $21/month), and that is the bottom rung: a build spread over several sessions usually lands on 200 credits at $50/month, or higher.
Compare Lovable plansSupabase project
Where your app keeps its data. Connect your own Supabase project from the chat, or let Lovable create one for you. Either way it designs the tables, adds the logins, and wires the screens to them from there.
Connect Supabase to LovableGitHub connection
Not needed to build anything, since Lovable keeps its own history of every change. Link a GitHub account and it also keeps a private repository in sync, so a copy of the real code exists outside the browser tab. Worth doing before the project is one you would hate to lose.
Set up GitHub syncOnly the first three are needed to start, and none of it touches your computer. From here, you describe what you want and Lovable builds it in the browser.
Build your editor, prompt by prompt
Everything below happens in one browser tab. Send a message, watch the preview rebuild, click through what changed, then send the next. One deviation from the usual Lovable order: the encoder comes before the database here, because it is the part worth proving early.
- 01
Set the ground rules, then get FFmpeg running
Unusually, the database can wait. Start by proving the encoder loads and cuts a file inside the preview, because everything else assumes it does.
PromptGet FFmpeg running in the previewBefore we build anything else, note the ground rules for this project: it is a browser video editor, the vocabulary throughout is projects, videos, clips, and exports, and all video processing happens in the visitor’s browser rather than on a server. Now prove that works: build one simple page with a file picker for a local video, a start and end time, and a button that trims it using FFmpeg compiled to WebAssembly and offers the result as a download. Use the single-threaded core loaded as a blob URL so CORS does not block it, and show the real progress rather than a spinner.
If this does not work in the preview, nothing built afterwards will help. It is the one step worth doing before the parts that feel more like progress.
- 02
Bookmark, then ask for the timeline on its own
The timeline is the biggest single piece of interface in the build, and the one you will iterate on most. Bookmark first so a bad direction is one click back.
PromptBuild the timelineBookmark the current version first. Then build the editor screen: a horizontal timeline holding clips end to end, each draggable to reorder and trimmable from either edge, with a playhead, a ruler marked in seconds, and a preview above that follows the playhead as you scrub. Keep all of it driven by one piece of timeline state, so a clip’s start, end, and position never disagree with what is on screen. Use placeholder clips for now.
Expect to send several follow-up messages on this one screen. That is normal for a timeline, and it is exactly why the bookmark matters.
- 03
Connect Supabase, then describe what gets saved
Now the database, and only now. The editor already works, so the tables are being designed around something real rather than something imagined.
PromptConnect the backend and design the tablesConnect this project to Supabase. Once it is linked, design the tables: projects, each owned by one person. Videos, each belonging to a project. Exports, each recording a finished render with the settings used and how long the result runs. Add a profile row per account. Every screen from here should read and write real Supabase data rather than placeholder content, and the media files themselves stay on the visitor’s device unless they explicitly choose to save one.
Say the last part out loud in the prompt. Left unsaid, an assistant will reasonably assume every file should be uploaded, which is the one thing this build is designed not to do.
- 04
Add logins and the access rules, then check them with the audit prompt
Ownership here is simple (each project belongs to one person) which makes it easy to get right and inexcusable to get wrong.
PromptAdd logins and access rulesAdd authentication: email-and-password sign-up, login, logout, and a profile row per person, with signed-out visitors sent to the login screen. Then three roles (visitor, user, and admin) stored in their own table rather than on the user account itself, because anything on the account can be edited by the person it belongs to, plus a helper the access rules can call without recursing. Then turn on row-level security for projects, videos, and exports: a person reaches only their own rows, an admin reaches everything, and every insert and update needs an explicit check that the new row is not being filed under someone else. Then show me how to confirm a second account gets nothing back for the first account’s projects.
- 05
Wire the export, with your formats
Join the two halves: the timeline you built in step 02 and the encoder you proved in step 01. Preview it after, because export is the moment people decide whether this is real.
PromptBuild the export flowConnect the timeline to the encoder. An Export button should turn the timeline (the trims, the order, and the chosen shape) into a real ffmpeg run in the browser, show honest progress while it works, and hand back a finished file. Offer widescreen, vertical, and square as presets rather than free cropping. Record each completed export in the exports table with its settings, and generate a thumbnail per clip locally. Use Select elements to point me at anything you want me to adjust rather than describing where it sits.
- 06Destination
Add demo mode and the admin view, then try it signed out
Demo mode is the highest-value thing left, because an editor sells itself if a stranger can touch it. Test it the way a stranger would.
PromptAdd demo mode, admin, and testTwo more pieces. Demo mode: someone with no account gets a throwaway workspace with a sample clip already loaded, backed by its own demo tables so nothing they do reaches real data. And an admin view of storage used, exports run, and accounts, visible only to the admin role. Then walk me through the whole thing in the preview: open it signed out and cut the sample clip, sign up, add a real video, trim and reorder it, export it vertically, and check that the export shows up in the dashboard and in the admin view.
What you hold, and what you never have to
This build has an unusual security position: the most sensitive thing in it (somebody’s unedited footage) never arrives unless you ask for it. Here is what that changes, and what still needs doing.
Proven logins
Sign-up, sign-in, and sessions come from a system that has been attacked for years and held, so nobody here is writing password handling. Email and password works immediately, with social sign-in a small addition when you want it.
The footage stays on their machine
Because the encoder runs in the tab, a file is read from the visitor’s disk and written back to it. Nothing about editing requires an upload, which means the raw footage is not sitting on your infrastructure waiting to be breached, subpoenaed, or paid for. It is worth saying so on the marketing page, because it is a real difference rather than a positioning line.
Three roles, and the demo visitor
The template ships visitor, user, and admin. The interesting one is the first: a stranger trying the demo needs to do real editing without an account, and without touching anything real. Give the demo its own throwaway tables rather than letting an anonymous session near production rows.
Row-level security across every table
The template ships 80 row-level security policies, and for once the rule they enforce is simple: projects, videos, and exports belong to exactly one person, and nobody else reaches them. The database applies that on every read and write, so a screen that forgets to filter still cannot show one person another person’s work.
Stored files need their own rules
Anything you do choose to keep (an export somebody saved, a source file they uploaded on purpose) is a file in storage rather than a database row, and needs its own access rules written alongside the table’s. A private projects table in front of a readable bucket is the version of this that looks finished and is not.
Almost nothing to keep secret
This template ships with no third-party API keys at all, which is rare here and is a direct consequence of on-device processing. The only secret is the database’s service key, and it stays on the server. The moment you add an AI feature you add your first real key (see below) so build the habit before you need it.
The database is the only copy until you pay for one
Projects and exports are records like any other, and the free tier keeps no backups of them. Supabase Pro, from $25/mo, adds a daily backup with 7 days of history. Losing a customer’s finished edit is a support conversation you do not want to have without one.
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.
Paste this into the chat before launch so Lovable checks nobody can see data they shouldn’t.
The one rule that matters: the database service key, 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.
What speeds the build, and what slows it
Speeds the build
- One small request per message, such as a field, a screen or a rule, rather than the whole app at once
- Connecting your database before building screens that need real data, not after
- Using Select elements to point at the exact thing that should change, instead of describing its location in words
- Bookmarking a known-good version before a redesign or a change to the data model
- Reading each response before sending the next request, so small mistakes don’t stack up
Slows the build
- Asking for an entire app in one message instead of one screen at a time
- Building screens for data your database does not hold yet
- Describing which button or section to change instead of selecting it
- Skipping bookmarks, then scrolling far back through history to undo a bad change
- Approving several messages in a row without previewing what actually changed
Connecting GitHub (Optional)
Every change in Lovable is saved automatically without any technical setup. You only need to link GitHub if you want a private copy under your own control or plan to hand the codebase over to external developers.
What Git actually is
A recorder for a project: every change becomes a version you can go back to, and nothing is ever overwritten. GitHub is the service that keeps those versions online.
Lovable already saves every change
A new version is created each time Lovable changes your project. No save button, no Git command, and the full history is there to scroll back through.
Version history, Lovable docsReverting undoes the code, not your data
One click restores an earlier version of your code and redeploys it, but nothing already written to your database rolls back with it. A UI or logic change is safe to undo. A change that touched real records is not.
Bookmark before a big change
Before a redesign or a change to your data model, bookmark the version you are on: one click back instead of a long scroll through history.
Connecting it, if you want to
Open your project settings, pick GitHub, and authorise the account. Lovable creates a private repository and keeps it in sync both ways: changes in Lovable reach GitHub, and anything pushed to that branch comes back in. Free on every plan.
GitHub integration, Lovable docsIt’s also how you leave, if you ever want to
The synced repository is a standard Vite and React project: clone it, hand it to a developer, or deploy it yourself.
Deployment, hosting, and ownership, Lovable docsWhere to put the app once it works
The app itself is a folder of static files, and it stays small no matter how much video passes through it, because none of it passes through it. One hosting question here that the other builds do not have is answered in the notes beside each host.
| Host | Best for | Notes | Free tier |
|---|---|---|---|
| LovableBuilt in | Publishing from the chat | The project you have been previewing publishes itself, with nothing to configure and no account to open anywhere else. Free on any plan at a lovable.app address. Paid plans put it on your own domain: buy one through Lovable and the DNS is done for you, or point one you already own at it using the two records the setup screen shows. Certificate issued automatically either way. | Free on a lovable.app subdomain · own domain on paid plans |
One button, and the app you have been previewing is live.
Hosting it somewhere else
Only for a setup Lovable does not offer: a host you already pay for, or the exported code on your own account. None of it is needed to go live.
| Host | Best for | Notes | Free tier |
|---|---|---|---|
| Vercel | One-click deploys | Connect the repository and it publishes on every push, with a Vite project needing no configuration. Response headers are configurable, which matters if you go multithreaded later. The free Hobby tier is personal, non-commercial only, so a product with users belongs on Pro at $20/user/mo. | Pro from $20/user/mo (Hobby is non-commercial) |
| Netlify | Drag-and-drop or Git | Connect the repository or drag the built folder in. Custom response headers are supported through a config file, so the multithreaded route stays open. | Free tier |
| Cloudflare Pages | Cheapest at scale | Serves from wherever is nearest the visitor, and supports custom headers. A reasonable default here, since the thing being served is small and static. | Generous free tier |
| GitHub Pages | Free Git-based hosting | Publishes from your GitHub project with one routing setting. Two catches: serving from a private repository needs a paid plan, and it does not let you set custom response headers, which closes the multithreaded option permanently. | Free from a public repo only |
| Firebase Hosting | Teams already on Google | One setup, then a single command per release, and headers are configurable in its own config file. Worth it mostly if Google is already your stack. | Free Spark tier |
| AWS Amplify Hosting | Teams already on AWS | Deploy from the AWS console with a rewrite rule for deep links, and custom headers available through its configuration. Sensible when AWS is already where your billing goes. | Free tier (build + hosting) |
| Surge | Publish from the terminal | One command puts the built folder online with no repository in the loop. Good for showing an early timeline to someone, less so for a product with headers to configure. | Free - unlimited publishing |
| DigitalOcean App Platform | DigitalOcean users | Point it at the project and it builds and serves it, alongside anything else in that account. | Free - 3 static sites, 1 GB/mo transfer |
Pick on two things here rather than one. The usual question is whether the plan allows commercial use. Vercel’s Hobby tier does not. The one specific to this build is whether the host lets you set custom response headers, because the faster multithreaded encoder needs them and the default single-threaded one does not. Building on the default and keeping the option open is the sensible order.
Faster exports have a hosting requirement, and it is worth knowing before you choose a host. The encoder ships in two forms. The single-threaded one this template uses runs anywhere with no special setup. The multithreaded one is considerably faster and needs SharedArrayBuffer, which browsers only expose to a cross-origin isolated page, meaning your host must send `Cross-Origin-Opener-Policy: same-origin` and `Cross-Origin-Embedder-Policy: require-corp` (or `credentialless`), per MDN. A host that cannot set response headers cannot run the fast path at all. Start on the default, and switch only if exports are genuinely too slow for your users.
Keep your data in Supabase
Records, accounts, and whatever files you decide to keep. Note what is missing: no transcoding service, because there is nothing left to transcode by the time a file reaches you.
| Service | Best for | Notes | Free tier |
|---|---|---|---|
| Supabase | Data, auth, files | Projects and exports in Postgres, accounts in auth, and storage for whichever files you decide are worth keeping. Make a free project, hand over the URL and publishable key, and it is connected. Keep an eye on one line only, storage, because finished videos are the sole large thing that ever lands here. | Free tier, then usage-based |
Add AI capabilities in one simple step
Securely route your AI API keys through a lightweight serverless function. Use simple prompts to automatically caption a cut, trim the silence out of it, and draft its title and description.
Captions from the audio
Transcribe the cut and lay the text over it as subtitles the user can correct. The most-requested feature in any editor, and the one people will otherwise leave to do somewhere else.
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.
Cutting the silence out
Find the gaps and the dead air, and propose cuts. Turns a rambling twelve-minute take into a tight four without anyone scrubbing through it by hand.
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.
Titles and descriptions from the cut
Draft the text that has to go around the video wherever it is published, from what the video actually says. It is the chore at the end that stops people shipping.
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.
Picking the thumbnail
Choose the frames worth using as a cover image, rather than making somebody scrub to find one. A small feature that removes a genuinely annoying step.
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.
You bring no key and pick no provider: Lovable manages an API key per project, and if you do not name a model it chooses one from what you describe. Match the model to the job: fast and cheap for anything that runs on every record, stronger only where the reasoning matters. Send every feature above through that one integration.
Get a head start with our template
Everything above assumes an empty folder. It does not have to be. The same editor exists already built, which turns the twenty hours of timeline work into an afternoon of deciding what your export presets should be.
Browser Video Editor
The exact video editor this guide builds, packaged so you can open it, point it at your own backend, and make it yours from there. A video editor that works in the browser: clips are trimmed, reformatted, and stitched right on the device, with no server needed to process video. Projects keep the work organized, and an export pipeline delivers the finished clip.
The key benefits of starting with a template
The timeline already works. That is most of what this saves you. Behind it, the projects, the storage rules, the export flow, the demo mode, and the admin panel are done too.
Building the core from scratch
~89 hrs
Opening the template, already built
~1 hr
~88 hrs of building you skip
Two different measurements, deliberately: ~89 hrs is what building the editor and everything around it costs you, and ~1 hr is how long the finished one takes to open and point at your own database. Shaping the formats and presets to your product takes the same time either way, so neither side counts it.
A working editor from day one
Open an app where clips already trim, reorder, and export. The timeline is the piece that takes weeks to build and minutes to evaluate, so start by using it rather than building it.
Accounts and access rules already wired
Three roles and 80 row-level security policies work out of the box, so each person reaches their own projects and nobody else’s, and the demo visitor reaches neither.
The awkward machinery already built
Loading the encoder, driving it from the interface, generating thumbnails locally, reporting real export progress, and the admin view over storage and exports. Each one is days you are not spending.
Clean structure your AI can safely customize
Types everywhere, files grouped by feature, comments where the reasoning is not obvious. That pays back harder here than on most templates: editor code degrades quickly when changes land without an existing pattern to imitate, and a tool with one to follow produces work that fits.
From founders who build on our templates
We needed a working product in front of users fast. I started from one of these templates instead of a blank repo, customized it in our AI tool, and shipped in days - not the weeks it usually takes.
Jeevan ThomasFounder & CEO, Hado.aiCommon questions
Not for editing, no. The encoder is compiled into the page and runs on the visitor’s own processor, so a file is opened from their disk, cut there, and written back there. The only things that reach your server are the ones you deliberately store: a project’s settings, and whichever finished exports you decide to keep.
No. Describe what you need in plain language and your AI coding tool writes the tables, the accounts, the access rules, and the storage rules. Your own job is creating a free Supabase project for it to point at, so the records end up somewhere you own.
That is a decision rather than a fixed number, and it is worth making early. A browser tab has finite memory, so long or high-resolution files are where it strains. Short clips at 1080p are comfortable on ordinary hardware. Set a ceiling you are happy to defend, tell people about it before they pick a file, and fail politely when they exceed it.
Because it is one browser tab rather than a whole machine, and by default it uses a single-threaded build of the encoder. A multithreaded build is meaningfully faster, at the cost of a hosting requirement: browsers only allow it on a cross-origin isolated page, which means your host has to send specific response headers. Start on the default and switch only if your users actually feel it.
Less than you would expect, because the expensive part of video is missing. No rendering bill arrives at any volume, because that work happens on your users’ devices. What is left is Supabase and a host, both starting free, with Supabase Pro from $25/mo once you have real users and free projects would otherwise pause. Your storage bill then depends entirely on how much you keep and for how long.
Yes, and this is the point where the template gains its first outside key. Captions are what most people add first, then silence trimming, titles and descriptions, and thumbnail suggestions. Add one small server-side function, route all of them through it, and keep the provider key on the server rather than in the app.
Yes, and for an editor it is worth the effort. The product demonstrates itself in about thirty seconds if you let it. The template ships a demo mode with its own throwaway tables, so a stranger can load a sample clip and cut it without an account and without touching anything real.
Nobody, unless you build that on purpose. Every project, video, and export belongs to one account, and the database enforces it on every query rather than trusting the screen to filter. Shared team projects and reviewer links are both possible, but both are features to design rather than settings to switch on.
Nothing here is proprietary. The records live in ordinary PostgreSQL, so a standard dump gives you every project and export in a form any Postgres host accepts, and stored files come out of storage the same way. The videos themselves were always ordinary files on ordinary disks.
Yes. Every host here connects a custom domain with free HTTPS in a few clicks. Worth doing before you invite anyone, since a tool asking people to open their own files deserves to look like it belongs to you.
No. Everything happens in a browser tab: you describe what you want in the chat, and Lovable writes and previews the code. The setup section above covers the handful of things you connect first: an account, a plan, and your own Supabase project.
A sketch on the Free plan is fine for testing an idea, with no real backend behind it. A project connected to your own Supabase account is the one you can actually launch, with real logins, real data, and your own domain.
Build credits reset every day (Free) or on your billing cycle (paid plans). If you run out mid-session, the app you’ve built stays exactly as it is. You either wait for the reset or move up a credit tier to keep going right away.
References
Sources checked August 2026- 01Pricing (per rendered minute), Shotstack. shotstack.io
- 02Pricing (credits, storage, video bandwidth), Cloudinary. cloudinary.com
- 03Pricing (quote-only licensing), IMG.LY. img.ly
- 04Pricing (plan volumes), Creatomate. creatomate.com
- 05Usage and multithreading requirements, ffmpeg.wasm docs. ffmpegwasm.netlify.app
- 06Cross-Origin-Embedder-Policy and cross-origin isolation, MDN. developer.mozilla.org
- 07Pricing (Pro plan, storage, egress, backups), Supabase. supabase.com
- 08Web developer hourly rates 2026 (freelance and agency benchmarks). developex.com
- 09Row Level Security, Supabase docs. supabase.com
- 10Storage access control, Supabase docs. supabase.com
- 11Sign up, Lovable. lovable.dev
- 12Subscription plans (Free, Pro, Business), Lovable docs. docs.lovable.dev
- 13Connect Supabase, Lovable docs. docs.lovable.dev
- 14GitHub integration, Lovable docs. docs.lovable.dev
- 15Deployment, hosting, and ownership, Lovable docs. docs.lovable.dev
- 16Version history and reverting, Lovable docs. docs.lovable.dev
- 17Preview toolbar (Select elements), Lovable docs. docs.lovable.dev
- 18AI features and model selection, Lovable docs. docs.lovable.dev
- 19Custom domains, Lovable docs. docs.lovable.dev
This guide is general information. Third-party prices, plan limits, and market rates are quoted from the sources above and were last checked on the date shown. Vendors change them without notice, so confirm before you budget. Export speed and the maximum practical file size depend on the visitor’s own device and browser, so treat any performance expectation here as a starting point to test rather than a specification. Build hours and the cost estimates derived from them are our own estimates, not quotes. Lovable is a product of Lovable Labs. Verify current capabilities and pricing before relying on them.