I built a browser inside my code editor — here's how and why

The Problem

When you're building a web app, your workflow usually looks something like this:

Edit code → Save → Switch to browser → Refresh → Check the result → Switch back to the editor.

Repeat that hundreds of times a day.

That browser switch seems small, but it adds up. When you're using a cloud-based editor, it's even more disruptive because your entire workspace lives in a single browser tab, and now you're constantly leaving it.

What I Built

I added an in-editor browser to Cloudpen, a VS Code-style cloud code editor I'm building.

It works like this:

• A Browser option in the Terminal menu opens a new tab inside the editor tab bar
• The tab includes a full address bar with back, forward, and refresh controls
• You can type localhost:3000 (or any URL) and load it directly inside the editor
• The tab title and favicon automatically update to match the loaded page
• A built-in DevTools panel provides a Console, Elements Inspector, and JavaScript REPL

The result is simple:

Run npm run dev in the integrated terminal, click the localhost URL, and see your application without ever leaving the editor.

The Technical Challenges

1. Same-Origin Policy

This was the biggest challenge.

An iframe loading localhost:3000 from an editor running on localhost:3001 is technically cross-origin because the ports are different.

As a result, the Elements Inspector and JavaScript console bridge only work for same-origin content and preview environments.

For external websites and production URLs, browser security restrictions prevent direct DevTools access. This is the same limitation that exists in VS Code's Simple Browser.

2. Favicon and Page Title Detection

For cross-origin pages, you cannot access iframe.contentDocument.title.

The solution I'm implementing uses a Next.js API route that fetches the target page server-side and extracts the <title> and favicon information directly from the HTML.

Because the request originates from the server, it bypasses browser CORS restrictions entirely.

3. Keeping the Browser Alive Between Tab Switches

React normally re-mounts components when they are removed and added back to the DOM.

That would cause the browser page to reload every time a user switches tabs.

The solution was to keep the BrowserPanel permanently mounted and simply toggle its visibility using display: none, preserving the browsing session and application state.

Is It Worth It Despite the Limitations?

Absolutely.

The primary use case is viewing a running localhost development server without leaving the editor, and that works exactly as intended.

The DevTools limitations only affect external production websites, where developers would typically use Chrome DevTools anyway.

For the workflow Cloudpen is designed around:

Write → Run → Preview

everything now happens in one place.

Cloudpen is a cloud-based code editor available at cloudpen.dev.

I'm building it in public and shipping new features every week.