I spent an afternoon looking at Panda Dock, an open-source browser sidebar toolbox that a developer shared recently. The pitch is tidy: a drawer that lives in your browser, parses selected text on a page, does JSON serialization and base64, and manages localStorage, sessionStorage, and cookies. It's the kind of thing every developer cobbles together from five different tabs, so bundling it makes sense.
The question I actually cared about was narrower. If I wanted to rebuild something like this on a hosting platform instead of an extension, how much of it would survive the move?
The honest answer is: about half. And the split is clean enough that it's worth walking through, because it tells you something about what belongs on the web and what belongs in the browser process.
The half that ports without a fight
JSON pretty-printing, JSON serialization, base64 encode and decode. These are stateless data transforms. Text goes in, text comes out, nothing is remembered between runs. That's the easiest category of software to host there is, because it has no dependency on where the user's data lives or what tab they're on.
You can build the whole front end as a single HTML page: a textarea for input, a textarea for output, a couple of buttons. For the light transforms, the browser can do the work locally in the page. When you run HTML online, that page is served and reachable immediately, no build pipeline, no bundler config to babysit.
The interesting decision is where heavier parsing goes. Small JSON blobs are fine in-page. But if you want strict validation, deep-nesting checks, large-payload handling, or conversions that are annoying to write correctly in JavaScript, you push that to a backend. That's where a Python endpoint earns its place. You can run Python online as a small API the page calls: send the raw string, let Python's json module do the parsing and error reporting, return formatted output plus a clear error location when the input is broken.
That division of labor is the part I'd actually defend in a review. In-page JavaScript for the instant, trivial cases so there's no network round-trip. A Python endpoint for the cases where correctness matters more than latency. You expose it through API Endpoint Hosting, the HTML page fetches it, and the two halves stay loosely coupled. If you later want to add a YAML-to-JSON converter or a JWT decoder, it's another endpoint, not a rewrite.
One thing to flag on security: if you host that Python endpoint, it's open to anyone who finds the URL unless you put something in front of it. For a personal formatter that's probably fine, but the moment you accept arbitrary input and do real work on it, you want at least basic rate limiting or a token check. Don't ship an unauthenticated parser that anyone can hammer and just hope nobody notices.
The half that genuinely doesn't port
Now the localStorage, sessionStorage, and cookie management. This is where the honest debrief has to say no.
Those features work in Panda Dock precisely because it's an extension. An extension runs inside the browser with access to the page's context and the browser's storage APIs. It can read and edit the cookies and web storage of whatever site you're looking at. That access is the entire point, and it's also exactly what a hosting platform cannot give you.
A page you host is just another website. It runs in its own origin. Browser security is built specifically to stop one origin from reading another origin's localStorage or cookies, and that's not a limitation you route around, it's the boundary that keeps the web safe. So a hosted tool can absolutely manage its own storage, but it can't inspect or edit the storage of some other tab. That requires a browser-extension runtime, and building or hosting browser extensions is outside what the platform does. I'd rather state that plainly than pretend a clever workaround exists.
So if the storage manager is the reason someone uses Panda Dock, cloning it as a web app is the wrong project. Keep it as an extension. There's no shame in a tool needing the runtime it needs.
What's actually worth building
Strip away the part that can't move, and you're left with a genuinely useful thing: a hosted set of data-transform tools that work from any machine, any browser, no install. That's a different value proposition from the extension, not a lesser one. The extension wins on being one keypress away inside your current tab. The hosted version wins on being a URL you can open on a locked-down work laptop, a colleague's machine, or your phone.
If I were shipping this, I'd start with a small suite: JSON formatter and validator, base64 both directions, maybe URL encode/decode. Each is an HTML page, sharing one Python endpoint for the heavy parsing. Then I'd think about the parts that benefit from actually being server-side, because that's where a hosted tool can quietly beat an extension.
Saved snippets, for instance. An extension stores your recent JSON blobs locally on one machine. A hosted tool backed by a SQLite database can let you save and name transforms and pull them up from anywhere. That's not a feature Panda Dock's evidence claims, so treat any performance or convenience comparison as unverified, it's just an option the architecture opens up. The point is you stop trying to copy the extension and start building the thing the web is good at.
The monetization angle is also more natural here than in an extension store. Because everything is a hosted page with an addressable backend, you can publish the suite, share it, and put the heavier or batch features behind access if you want. Bundling small developer utilities into a published set of online tools is a low-drama way to ship something real without committing to a full product.
The takeaway
The useful lesson from picking Panda Dock apart is that "can I rebuild this? is the wrong question. The right one is "which parts of this depend on the browser runtime, and which are just functions?
The functions, JSON and base64, port cleanly and even improve when you give them a proper backend and storage. The runtime-dependent parts, cookie and web-storage editing, stay where they are because the browser's security model says so.
Know which half you're holding before you start. Clone the transforms, leave the storage manager as an extension, and don't sell anyone on a capability the platform doesn't have.