How to edit a live web page without changing the code
"Edit a live page" means three different things, and only one of them needs a developer. Here's which is which.
Can you edit a live web page without changing the code?
Yes — and the confusion around this question comes from three different jobs sharing one sentence.
Before picking a tool, decide which one you're doing: seeing a change yourself, showing a change to other people on the real page, or shipping a change so your visitors get it. Only the third one touches your codebase, and most of the time people asking this question want the second.
Three things people mean by "edit a live page"
| What you want | What does it | The catch |
|---|---|---|
| See a change on the page, right now, for yourself | Browser devtools | Vanishes on refresh, needs CSS or HTML, and there's nothing to hand to anyone |
| Show a change to your team on the real page | 6to9 | It's your browser's view of the page, not the published page |
| Change what a slice of visitors sees, as a test | Your experimentation platform | Needs its script installed on your site first |
| Change what every visitor sees, permanently | Your CMS, or your codebase and release process | Content is usually self-serve; structure needs whoever owns the template |
| Restyle a site permanently, just for you | A userstyle or userscript extension | Only you ever see it, and it's styling rather than content |
The row most people are looking for is the second. You don't want to permanently change the page — you want a version of it that's real enough to react to, so the argument about whether it's right can happen before anyone builds it.
How to edit a live page with 6to9
6to9 is a browser-level agent: a Chrome extension you open on the page itself. Nothing is added to the site, so there's no script, no tag, and no CMS to be on.
- 1
Open it on the page you want to change
Any page your browser can load — a landing page, a pricing page, a dashboard behind your own login. The real page, with its real content and styles.
- 2
Say what you want different
Describe it in plain language — "make the headline about the time saved, not the features" — or select the element and adjust it by hand, dragging it to the exact size and position you want. The page changes in place while you look at it.
- 3
Keep going until it's right
Try the other version. Then a third. The cost of another attempt is a sentence, so nothing has to be right first time, and the first idea doesn't win by default.
- 4
Share it as a link
Whoever opens it sees the same change on the same real page, rather than a screenshot of what you meant. If they have 6to9 too, they can edit on top of your version and share theirs back — the new link carries both.
- 5
Hand the agreed version over
Once everyone's seen it, it goes to whoever changes that page — your CMS for content, your engineer or coding agent for structure — and ships the normal way.
Two ways to make the change
Plain language is the fast path, and it's the right one when you know the intent but not the specifics: "make the headline about the time saved", "move the form above the fold", "add a row of logos under the hero".
It's the wrong path when you already know exactly what you want. "Make it a bit smaller" is a worse instruction than doing it yourself, so you can also select the element and adjust it by hand — drag to resize, drag to reposition, nudge it to the size and place you actually meant. Select several elements and change them together when they should stay consistent.
Most real edits use both: describe the change to get it roughly right, then take hold of it and settle the details. That combination is why the result looks like a designed page rather than an approximation of one.
What you can change, and what you can't
You're editing the page as your browser rendered it, which means the visible layer is all in scope: copy, headings, button labels, the order of sections, spacing and styling, images, and adding or removing whole elements like a testimonial block or a trust row.
What that layer can't do is change what the server decides. If your pricing is calculated, your search results come from a query, or a form posts somewhere specific, editing the page changes how those things look, not how they behave. For a landing page that distinction rarely matters. For a checkout or a dashboard, be clear with yourself about which one you're demonstrating.
One consequence of working on the real page rather than a copy: if the page needs a login, anyone you share the change with needs their own access to it. That's usually fine inside a team and worth knowing before you send the link to someone outside it.
Sharing is where the editing continues
The link isn't the end of the edit. Anyone who opens it sees your change on the real page — and if they have 6to9 too, they can keep going from there: change what you did, add something you missed, and share their version.
That version arrives with its history attached. The new page shows the change they made and the ones it was built on top of, so nobody has to reconstruct who changed what. A designer tightens the spacing on the copywriter's headline, a PM adds the proof row, and the last link contains all three — still on the real page, still nothing published.
This is the part that's hard to do any other way. Comments on a screenshot accumulate opinions; nobody's edit builds on anyone else's, and someone has to translate the whole thread at the end. Here the edits build on each other directly, and there's nothing left to translate — the final link is the agreement.
Why not just use browser devtools?
Because devtools solve the first job and none of the others.
Editing HTML in the elements panel does change the live page in front of you, and for a quick "what if this headline were shorter" it's the fastest thing there is. But the edit disappears the moment the page reloads, making it requires knowing CSS and HTML, and there is no way to hand the result to your designer or your VP — you're back to a screenshot with arrows on it, which is the thing that started the problem.
The useful mental model: devtools change your view of the page for the next few minutes. A tool like 6to9 changes your view of the page and then makes that view something other people can open. Your CMS or your release process changes the page itself.
Start with the change you can't get made
If you're reading this, there's probably a specific page and a specific change behind it — a headline that undersells, a form asking for too much, proof that isn't there. The reason it hasn't happened usually isn't that anyone disagrees; it's that describing it takes longer than it should and the description arrives back wrong.
Open the page, make the change on it, and send that instead.
Frequently asked
Does editing a live page change it for other people?
No. The change happens in your own browser, on top of the page as it loads. Your visitors see the site exactly as it was, and nothing about your site has changed. The only people who see your version are the ones you send the link to.
Do I need to install anything on the website itself?
No. 6to9 installs in your browser as a Chrome extension — there's no script to add to your site, no tag to deploy, and nothing for your engineers to review before you can start.
Will the change survive a page refresh?
The edit isn't written into the page, so a plain refresh shows the original — but the change is saved as a prototype you can reopen on that page whenever you want, and share as a link. That's the difference from browser devtools, where a refresh loses the work permanently.
Can I edit a page I don't own?
Technically you can open 6to9 on any page your browser can load, and that's genuinely useful — an agency prototyping a change to a prospect's public landing page for a pitch, for example. Use it on pages you own or are authorized to work on, and when you share a change to someone else's site, be clear that it's a proposal rather than something that's live.
Does it work on pages behind a login?
Yes. Open it on the page while signed in as yourself and a dashboard, onboarding step or settings screen behaves like any public page. One thing to know: anyone you share the link with needs their own access to that page, because the change is applied on top of the real page rather than a copy of it.
How do I make the change permanent?
Through whatever normally changes that page — your CMS if it's content, your codebase and release process if it's structure. The point of editing the live page first is that everyone can see and agree on the change before anyone spends time building it.
Published July 29, 2026
6to9 is a Chrome extension — open it on any page you're allowed to change and describe what you want different. Install it for Chrome, or have us walk one of your pages.