Web tools are often thought of as something you open by URL each time, but HTML, CSS, JavaScript, and other required assets can sometimes be bundled into one HTML file that acts as the tool itself. That file can be copied to a USB drive or shared folder without carrying a directory of supporting assets, which is convenient for some workflows.

However, "everything is in one HTML file" is not the same as "works without a network", "never sends input data elsewhere", or "keeps all of your working data inside the HTML". Browser Kitty tries to distribute tools as single HTML files whenever practical, but there are still several things to check before relying on a saved copy. This guide separates the real benefits from the common assumptions.

Separate these three ideas

Packaging

Single HTML

Packaging HTML, CSS, JavaScript, and related assets into one file. This alone says nothing about runtime network access.

Network

Offline use

Using the main features without runtime network access. A single HTML file can still fail offline if it depends on external services.

Data handling

Fully local processing

Processing user files and input on the device without sending them to an external service. This is separate from the packaging format.

A single HTML file keeps the tool together

A typical web page may be split across HTML, CSS, JavaScript, images, fonts, Workers, WASM, and other files. A single-HTML build embeds as many of those pieces as practical into the HTML itself. You do not have to preserve a directory structure when storing it; copying one file is often enough to keep the tool together.

Keeping a known version can also be useful when the same tool is used repeatedly for a fixed workflow. Even if the hosted web version changes later, the saved HTML remains the version you downloaded, which can make it easier to use alongside a documented procedure.

Single HTML does not automatically mean offline

Even one HTML file can load a library from a CDN, fetch an external font or image, or call an API after it starts. In that case the distribution is one file, but part or all of the tool can still depend on a network connection. If offline use matters, runtime network dependencies must be checked separately.

Browser Kitty tries to avoid runtime external dependencies in tools designed for fully local processing. Browser security requirements are a separate issue, however. Features such as camera or microphone access can depend on how the page is opened, and some browsers restrict them when an HTML file is opened directly through `file://`. Check whether the specific tool requires HTTPS or localhost.

Single HTML and fully local processing are separate claims

Single HTML describes a distribution format; it does not determine where user files or input are processed. A single HTML file can technically upload data to an external API, while a multi-file web app can still perform all processing on the device.

  • If privacy matters, do not rely on the words “single HTML” alone
  • Check separately whether files or entered data are transmitted elsewhere
  • When Browser Kitty says “fully local processing,” it is intended to mean user data is not sent to an external service

Copying the HTML may not copy your working data

A tool can be distributed as one HTML file while storing settings or history in browser storage such as `localStorage` or IndexedDB. In that design the HTML is the application code, while the working data lives separately in the browser. Copying only the HTML to another computer does not automatically bring the previous device’s data with it.

  • Check-in Desk application file: can be copied as a single HTML file
  • Roster and check-in history: stored separately in browser storage
  • Before moving devices or clearing browser data: save a JSON backup

A saved copy does not update itself

Once downloaded, the HTML is separate from the latest hosted version. That is useful when you want to keep a version you have already tested, but bug fixes, browser-compatibility changes, and dependency updates are not applied automatically. When returning to a saved copy after a long interval, it can be worth checking the original source for a newer release.

  • Record the version and download date in the filename or a nearby note
  • Keep the publication URL or GitHub repository with the saved copy
  • For tools that depend on browser APIs, recheck the latest release and browser requirements before returning after a long interval

Treat HTML as executable code, not a passive document

An HTML file is a document format, but with JavaScript it can also execute application logic. Depending on browser permissions, it may make network requests or use features such as file selection, the clipboard, camera, or microphone. For that reason, an unknown HTML file should not be treated as harmless just because it opens in a browser.

When keeping a local copy, obtain it from a trusted source such as the official site or public repository and review the published source or privacy notes when appropriate. If you pass the file to coworkers or family members, keep enough context to show where it came from and what the tool is intended to do.

When single-HTML tools fit well—and when they do not

Instead of asking only whether something can be packed into one HTML file, first ask whether the task naturally belongs inside one browser on one device. The less it depends on continuous server communication, the more useful the one-file format tends to be.

  • Good fit: occasional small utilities, file processing, small calculations, viewers, and workflows that benefit from keeping a tested version
  • Poor fit: simultaneous multi-user editing, cloud synchronization, tasks that always need fresh server data, or services centered on accounts and backend databases

Three things to check before using a saved copy

This may sound like a lot to verify, but everyday use does not require a technical audit. Trying these three simple checks covers most of the problems you are likely to meet after saving a copy.

  1. Check the explanation and sourceRead the official page or README sections about privacy and network access so you know what data is processed on the device. If the explanation is unclear, start with harmless test data rather than personal or confidential files.
  2. Try the saved copy yourselfSave the HTML, double-click it, then test the actions you actually need: loading input, processing it, and saving the result. If offline use matters, try with the network disconnected. For camera or microphone tools, confirm those features can start from the saved copy.
  3. See how working data is keptCreate one harmless test setting or history item, close the page, and open the same HTML again. If the data remains, look for Backup or Export, save one test backup, and confirm whether an extra file is needed when moving to another computer.
If you want a more technical check

To inspect network access in more detail, open the Network panel in Chrome or Edge Developer Tools, clear the list, reload the page, and use the main features. Requests to external URLs show where the page is connecting and can be checked against the tool’s README or privacy notes. Treat this as supporting evidence rather than a complete security audit.

To inspect stored settings or history, open the Application panel in Developer Tools and look at Local Storage or IndexedDB. Data shown there is stored by the browser separately from the HTML file.

Try it in Browser Kitty

Check-in Desk

Reuse a roster for check-in, attendance, and entry/exit sessions, then review history and export CSV or JSON on one device.

Open toolView tool details

Tips and limitations

  • It helps to separate three ideas: single HTML is a distribution format, offline describes network dependence, and fully local processing describes where user data is handled.
  • Before moving a saved HTML to another device, check whether you also need browser-stored data. Some applications do not carry that data inside the HTML file.
  • A single HTML file can still be tens of megabytes or more when it embeds WASM or AI models, so check file size before using email or other transfer methods.
  • For long-term storage, record the original GitHub repository or publication page alongside the HTML so you can find updates later.

Frequently asked questions

Does a single HTML file always work offline?

No. A one-file app can still contact a CDN or API after launch. Offline use requires checking that the tool has no runtime dependency on external services.

Does single HTML mean my files are never uploaded?

No. Single HTML only describes how the app is packaged. Whether it transmits user data is a separate question that must be checked in the app's privacy and runtime behavior.

Will settings and history move when I copy the HTML to another computer?

It depends on the tool. If settings or history are kept in browser storage such as `localStorage` or IndexedDB, copying the HTML alone will not transfer them. Check for export or backup features.

Will a saved HTML keep working forever?

There is no guarantee. The saved file itself does not change, but browser APIs and permission rules can change around it. Check the original source for a newer release when returning after a long time.

Is it safe to open an HTML file sent by an unknown person?

It is better not to. HTML can execute JavaScript, so an unknown file should not be treated like a passive document. Prefer copies obtained from a trusted source.

References

The points about runtime network access, browser storage, file-URL behavior, and camera or microphone permissions are based on the following specifications and official documentation. Actual behavior can vary by browser and by how the tool is implemented.