Every marketing site eventually hits the same wall: someone spots a typo, a stale price, or a headline that's testing badly, and fixing it means either a Slack message to a developer and a wait for the next sprint, or migrating the whole site to a headless CMS just so non-developers can touch text. Both options are wildly disproportionate to "please change three words."
I built Editbar as the narrow middle ground: a floating admin bar you drop into any customer-facing site with one script tag, that lets whoever owns the content edit it in place — no CMS migration, no per-framework SDK, no build step.
What it does differently
Most "edit your content" tools want you to either restructure your content as Markdown/JSON and adopt their data layer (Tina-style), or install a per-framework SDK (Weglot-style). Editbar does neither. You mark existing text with a plain HTML attribute:
html
<span data-edit-id="hero.title">Welcome to Acme Studio</span>
...
<script src="https://your-editbar-server.example.com/widget.js" defer></script>
That's the entire integration. data-edit-id is just an HTML attribute, so it survives being rendered by React, Vue, Astro, a static site generator, WordPress, or hand-written HTML — the widget doesn't know or care what rendered the page, it just patches matching elements after load.
How the save flow works
Clicking "Edit" on the bar makes any marked text directly editable on the live page. Changes are cached in localStorage until you explicitly hit "Save changes" — nothing is public the moment you finish typing. Saving posts to the reference server's POST /overrides endpoint, which writes to a flat overrides.json file (atomic write via temp file + rename, so a crash mid-write can't corrupt it). Every visitor's page load fetches the current overrides.json and patches the matching elements — so a publish propagates to everyone on their next load, with no rebuild or redeploy. The full flow, including how conflict detection and blame are layered on top, is in docs/ARCHITECTURE.md.
The security model
This is meant to run on other people's production sites, so I spent real time here rather than treating it as an afterthought:
One server-side check is the whole gate. GET /overrides.json is public by design (visitors need to see the live text); POST /overrides independently verifies a bearer token server-side on every write. The bar's visibility in the UI is cosmetic — even a spoofed or forced-open bar can never write without the real token.
Writes never touch innerHTML. The free/self-hosted core patches text via textContent only, so an admin (or anyone who leaked a token) can change what visitors read, never inject markup or scripts.
The token is scoped per backend, not just per host, in localStorage — so embedding two different Editbar instances on one page can't cross-contaminate each other's admin token.
A no-referrer meta tag is injected as early as possible when the page loads with a one-time ?edit_token= link in the URL, to limit that token leaking into third-party Referer headers from analytics/ad scripts already queued on the page.
The elephant in the room: the admin token lives in localStorage with no expiry or origin/path scoping — a deliberate tradeoff of the shared-secret model, not an oversight. If your own site has an unrelated XSS vulnerability, that XSS can read the token, the same way it could read any other secret you kept in localStorage. Editbar doesn't introduce that risk, but it doesn't shield you from it either — this and every other tradeoff is written up in the architecture doc rather than left for someone to discover the hard way.
What it deliberately doesn't do (yet)
The free, self-hosted core is plain text only — no rich content (images, links), no multiple admins/roles, no version history, and no SEO-guaranteed rendering (overrides patch in client-side, so non-JS scrapers and link-preview bots see the original text, though Google's own renderer sees the edited version). None of this is artificially crippled — it's scope, not a paywall inside the OSS code. A hosted version is planned on top of the exact same core for teams that want those features without running their own backend; see the Roadmap in the README for where that's headed.
Try it
Repo: https://github.com/jindrabe/editbar
Quick start (self-host in a few minutes): see the README
Architecture / security model: docs/ARCHITECTURE.md
Hosted app: https://editbar.online
MIT licensed. Happy to answer questions about any of the tradeoffs above — most of them were deliberate, and I'd rather defend them in the comments than have someone find the sharp edge in production.
