Free online web editor with preview function

Overview

This app is a browser-based editor for local web projects. It is designed for the common front-end file types people often need together: HTML, CSS, JavaScript, SVG, XML, images, and other small project files. The editor shows a project tree on the left, one editable file in the middle, and a preview area on the right. Users can resize the panes, temporarily hide panes, import files or folders, create new files and folders, and download the whole project as a ZIP.

The goal is not to replace a full desktop development environment. The goal is to provide a practical, private, easy-to-host tool for quick web editing and preview work directly in the browser. That makes it useful for lightweight development, content editing, HTML landing pages, training materials, website maintenance, education, and controlled editing tasks where a full IDE would be unnecessary.

Who this app is for

User guide

1. Open the app

Open the app in a desktop Chromium-based browser if possible. The app shows a warning on startup in browsers or devices where support may be weaker. The warning can be dismissed. It is only a compatibility notice, not an error.

2. Start a new project or add an example project

Use the File menu in the top bar.

• New project clears the current local project and starts with an empty storage area.
• Add example project loads a small demo project that shows HTML, CSS, JavaScript, and SVG preview behavior.

3. Add files or import an existing folder

The file menu lets you create a new file, create a new folder, import individual files, or import a folder from your computer. You can also drag files or folders into the drop area. Imported folders are preserved as folders inside the project tree, so relative links can continue to make sense.

4. Open a file in the editor

Click a file in the tree to open it. This version works with one open file at a time. If you modified the current file and try to open another file, the app asks whether to save, discard, or cancel.

• Text files open in the editor.
• Binary files show a note that the editor only supports text files.
• SVG is treated as text in the editor and as an image in preview.

5. Save changes

Click Save to write the current file back into local browser storage. Unsaved changes are tracked in memory while the file is open.

6. Preview the file

The preview pane behaves differently depending on file type.

• HTML is rendered inside an iframe-based preview environment.
• Images are displayed directly and can be zoomed in or out.
• SVG can be edited as text and previewed visually.
• Other files may not show a visual preview.

7. Adjust settings

Open the Settings menu to change the theme, editor font size, editor font family, and syntax highlighting. Syntax highlighting is optional and off by default.

8. Hide or resize panes

Each pane has a hide button. Hidden panes can be restored from the restore dock. Splitters between panes let you resize the file tree, editor, and preview widths.

9. Download the project

Use Download ZIP from the file menu to export the project as a single ZIP archive.

Current features

Browser support and compatibility

The app is primarily designed for desktop Chromium-based browsers. That includes Chrome, Edge, Brave, Opera, and other Chromium derivatives. These browsers generally provide the strongest support for the storage and preview behavior used by this app.

The app may still work partly in other browsers, but some behaviors can be weaker or inconsistent. For that reason, the app shows a compatibility warning on startup when the browser looks less suitable.

Why Chromium-based desktop browsers are preferred

• stronger support for drag-and-drop file and folder workflows
• reliable IndexedDB behavior for local structured project storage
• better support for preview-related browser APIs used in this app
• more predictable behavior for the iframe preview environment used by the editor

Mobile support

Mobile use is not the primary design target. The layout is large and pane-based, which is naturally more suited to desktop screens. Basic usage may work on mobile or tablets, but the user experience and browser feature support may be limited.

How local storage works

Project files are stored in the browser using IndexedDB. User interface settings such as theme, font size, font family, syntax highlighting preference, and the dismissed compatibility warning are stored in localStorage.

Database: cl-web-editor-db
Version: 1
Object store: projectEntries
Key path: path

Settings key: cl-web-editor-settings
Warning key: cl-web-editor-warning-dismissed

Why IndexedDB was chosen

IndexedDB is built into modern browsers and is suitable for structured local data. It allows storing many project entries without needing a backend. It also fits the requirement that the whole tool should remain browser-only and self-contained.

What "local" means here

The stored project belongs to the browser profile and the exact site origin where the app is hosted. If you deploy the app under a different domain, subdomain, or port, that is treated as a different origin and it gets a different storage area. That means a project stored on one origin will not automatically appear on another origin.

How preview works

Preview is the most technically unusual part of the app. A normal browser page cannot simply open a local project folder and behave like a real web server. To make preview useful anyway, the app builds a browser-side preview layer that simulates common static website behavior.

High-level preview flow

1. The selected HTML file is parsed with DOMParser.
2. The document is given a synthetic base URL under https://preview.local/.
3. Known asset references such as CSS, scripts, images, subtitles, posters, icons, and source sets are rewritten.
4. A preview runtime script is injected into the document.
5. The final HTML is turned into a blob URL and loaded into an iframe.

Why a synthetic preview origin is used

The app needs a stable URL context so relative paths like ./style.css, root-relative paths like /article.css, and fetch requests like fetch('videos-basic.csv') can be resolved in a predictable way. The synthetic origin gives the preview a consistent URL base without requiring a real server for the project itself.

What gets rewritten for preview

The app rewrites a broad set of common asset references so local projects can preview more realistically.

• img src
• script src
• link href for stylesheets and icons
• source src and source srcset
• video src and video poster
• audio src
• track src for subtitle files
• object data and embed src
• iframe src
• a href when it points to local project HTML files
• CSS url(...) and @import
• inline style attributes that contain URLs

How JavaScript fetch and XMLHttpRequest are handled

Static rewriting alone is not enough for modern HTML pages. Many pages generate URLs at runtime or load local data with JavaScript. To support that, the preview runtime patches browser behavior inside the preview document.

• window.fetch is intercepted for local project files.
• XMLHttpRequest is intercepted for local project files.
• runtime property assignments like img.src = ... or video.poster = ... are rewritten when possible.
• setAttribute() is patched for common URL-bearing attributes like src, href, poster, data, and srcset.

Why the iframe sandbox warning may appear

Developers may notice a browser console warning that says an iframe using both allow-scripts and allow-same-origin can escape sandboxing. In this app that warning is expected. The preview needs script execution and same-origin-like behavior to make local asset loading and fetch simulation work. The warning is about capability, not necessarily about an active failure.

Syntax highlighting design

Syntax highlighting is deliberately optional and off by default. The editor must remain usable even without it. This keeps the basic editing path simple and avoids forcing extra rendering work on every user.

Supported file types

• HTML
• CSS
• JavaScript
• XML
• SVG through the XML-style path

How it is implemented

The editor uses a layered model instead of a contenteditable code editor or a large external highlighting library. A transparent textarea remains the actual editing surface, while a synchronized pre element underneath shows the colored tokens. This approach keeps input behavior simpler and avoids external dependencies.

Why it is intentionally simple

This highlighter is not meant to be a full parser. It is a practical token-based layer that improves readability for common front-end file types. That is enough for this project's purpose and keeps the implementation maintainable.

Developer architecture

Technology stack

• HTML5 for structure
• custom CSS for layout and theme
• vanilla JavaScript for state, storage, preview, and export logic
• IndexedDB and localStorage for local persistence
• no external JavaScript libraries

Why no framework is used

The project is intentionally small and self-contained. A framework would add dependency weight, licensing questions, update burden, and a more complex build story without solving a real problem for this app. Vanilla JavaScript is enough for the interaction model used here.

Single-file-open workflow

This build supports one open file at a time. That keeps state management simpler, especially for save prompts, preview updates, and syntax highlight synchronization. The code can later be extended to multiple tabs, but the current version intentionally avoids that complexity.

High-level application flow

DOMContentLoaded
  -> load settings from localStorage
  -> apply theme and editor settings
  -> show or hide browser compatibility warning
  -> bind UI events
  -> load project entries from IndexedDB
  -> render file tree
  -> restore pane visibility
  -> update editor state
  -> update syntax highlight
  -> update preview

Important functional areas in the code

Suggested repository structure

/web-editor/
  index.html          -> documentation page
  /app/
    index.html        -> application shell
    web-editor.css    -> app styling
    web-editor.js     -> app logic
  LICENSE             -> GPL 2.0 license text
  README.md           -> repository readme

Project data model

Every project entry has a normalized path and is stored as either a folder or a file. Files can be text or binary.

Folder entry

{
  path: 'images',
  kind: 'folder'
}

Text file entry

{
  path: 'index.html',
  kind: 'file',
  mime: 'text/html;charset=utf-8',
  encoding: 'text',
  content: '<!doctype html>...'
}

Binary file entry

{
  path: 'img/thumbnail.jpg',
  kind: 'file',
  mime: 'image/jpeg',
  encoding: 'dataurl',
  content: 'data:image/jpeg;base64,...'
}

Why this model was chosen

This format is simple to serialize into IndexedDB, easy to export to ZIP, and flexible enough to store both code files and image assets. The path-based model also makes relative URL resolution more straightforward during preview generation.

Deployment and system administration

What the server does and does not do

The server only needs to deliver static files for the documentation page and the app itself. It does not need PHP, Python, Node.js, a database, or any server-side project processing. All actual editing, storage, preview generation, and ZIP creation happen in the browser.

Recommended hosting approach

• host the app over normal HTTP or HTTPS, not file://
• serve /web-editor/app/index.html, /web-editor/app/web-editor.css, and /web-editor/app/web-editor.js as static files
• serve the documentation page at /web-editor/
• keep JavaScript enabled in the browser environment

Why normal HTTP or HTTPS is recommended

Browser storage APIs and blob preview behavior are much more predictable when the app is served from an origin. That is also how users will normally access the tool in practice.

Simple local test environment

For development or internal testing, a basic local web server is enough. A Python HTTP server is often sufficient for checking layout and general browser behavior.

python -m http.server 8000

Cache and update behavior

Because this is a pure client application, browsers may cache the app shell. During upgrades, system admins may want to use sensible cache rules or versioned deployment habits, especially when users are repeatedly testing a fast-changing build.

Storage implications for admins

User project data is stored in the browser, not on the web server. Clearing the server cache does not clear user projects. Clearing browser site data on the client side does remove the stored project for that origin.

Privacy and security model

Privacy benefits

• project files do not need to be uploaded to a server for editing
• the app has no registration and no account requirement
• there are no ad trackers inside the editor itself
• the tool is suitable for private internal HTML work and unpublished assets

Security design choices

• no external JavaScript libraries are required
• all storage is origin-local in the browser
• the preview runs inside an iframe instead of directly replacing the app shell
• preview URLs are created as blob URLs and managed explicitly

Important trust assumption

The preview is meant for local project code that the user chooses to inspect or edit. Because previewed HTML and JavaScript are allowed to run inside the preview environment, users should treat the preview as trusted project code. This is normal for a local editor, but it is still important to understand.

Limitations and trade-offs

Important current limitations

• not a full IDE
• not a real dev server
• one open file at a time
• no built-in rename, move, or delete workflow in this version
• no terminal, debugger, git integration, or package manager support
• no back-end execution
• syntax highlighting is intentionally simple and only for selected file types
• mobile support is secondary

Preview limitations

The preview layer is strong for many static-site cases, but it still cannot perfectly emulate every server behavior. Examples of cases that may need a real local server or a full desktop tool include:

• complex ES module graphs with strict server expectations
• service worker registration and caching behavior
• server routes, rewrites, cookies, or authentication flows
• HTTP methods beyond common local read-style use
• backend API endpoints that must actually exist

Why these limitations are acceptable here

This app solves a narrower problem well. The project chooses focus and portability over trying to become a complete replacement for desktop development tooling. That keeps the codebase smaller, easier to audit, easier to self-host, and more realistic for CasinoLove's open-source browser app line.

Possible future additions

The current architecture leaves room for expansion. Future work should stay modular so the app can grow without losing its lightweight nature.

• multiple editor tabs
• rename, move, and delete actions
• search across files
• better code navigation and line tools
• more syntax highlighting languages
• optional prettier formatting helpers
• better preview navigation history
• project templates beyond the current example project
• better import and merge behavior instead of replace-only example loading

FAQ

Does the app upload my files to a server?

No. The project is stored locally in the browser for the site origin where the app is running.

Can it preview JavaScript-based pages?

Yes, for many common static-site cases. External local scripts, inline scripts, local fetch calls, and local XMLHttpRequest calls are supported in the preview layer.

Can it preview images and SVG files?

Yes. Images are previewed directly and can be zoomed. SVG can be edited as text and previewed visually.

Does it support syntax highlighting?

Yes, but it is optional and off by default. The current supported languages are HTML, CSS, JavaScript, XML, and SVG-style XML.

Where is my project saved?

In IndexedDB for the current browser profile and site origin.

Will my project appear on another domain or another browser?

No. Browser local storage is origin-specific and browser-specific.

Why is there a browser warning at startup?

Because the app is mainly designed for desktop Chromium-based browsers. The warning helps set realistic expectations on browsers where support may be weaker.

Why not use Monaco or another large editor library?

The app is intentionally lightweight and self-contained. Avoiding heavy third-party editor libraries keeps the source code smaller, the dependency surface lower, and the long-term maintenance story simpler.

Why is GPL 2.0 used?

This project is being published as open source under GPL 2.0 through CasinoLove's GitHub repository. The exact legal terms are defined by the LICENSE file in the repository.

Conclusion

This web editor is a focused browser tool for local static web project work. It combines a file tree, text editor, preview environment, local persistence, and ZIP export in a small self-hostable package. Its design favors privacy, simple deployment, and practical web editing over feature overload. That makes it useful both as a real working tool and as a clear open-source foundation that developers can extend.