# Build a single-file HTML document that travels well

Canonical: https://githtml.com/guides/portable-single-file-html-document
Published: 2026-09-26
Publisher: WaveTech LLC / gitHtml

Put the complete document body and its essential CSS in one .html file. Prefer system fonts, static navigation, and text explanations that do not require network requests. Treat images, scripts, and linked stylesheets as explicit dependencies rather than assuming that a reader will mirror the surrounding repository or website.

## Define what must survive

Portability begins with an editorial decision: which information must remain available when the original site is unreachable? For an incident summary, that usually includes the timeline, impact, corrective actions, and owners. A logo, live dashboard, or animated chart is secondary. Write the required facts as HTML text before choosing presentation details.

Keep a small dependency inventory next to your authoring process. List every stylesheet, image, font, script, frame, and external data request. Mark each item essential or optional. An essential remote dependency is a design problem to resolve, not something to conceal behind a reassuring label such as self-contained.

## Keep the structure ordinary

Use a document title, language attribute, character encoding, viewport declaration, and semantic body elements. Inline the modest CSS needed for typography and spacing. This does not mean putting style attributes on every paragraph; one style element can hold shared rules for the entire document. A system-font stack avoids a font download becoming a prerequisite for reading.

Small embedded images can be appropriate when their additional file size is acceptable. Large photographic collections are different: embedding everything can produce a cumbersome document. Consider a concise text-led report with selected illustrations and clearly labeled external galleries instead. The portable artifact should preserve the argument, not necessarily every visual asset from its source.

## Package and inspect the result

Use this minimal shell as a starting point, then insert real headings and paragraphs. After authoring, review the actual file that will be committed, rather than a development preview that may supply hidden dependencies. In gitHtml, optional JavaScript and remote resources start off, which makes static completeness particularly useful.

1. Move the file away from its original asset directory during a local inspection.
2. Confirm that every essential statement remains understandable without pictures.
3. Check the resulting file size before adding more embedded media.

````html
<!doctype html>
<html lang="en">
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>Service review</title>
<style>
body { max-width: 68ch; margin: auto; padding: 1rem; font: 1rem/1.6 system-ui; }
img, svg { max-width: 100%; height: auto; }
</style>
<main><h1>Service review</h1><p>Summary goes here.</p></main>
</html>
````

## Sources and further reading

- [MDN: the style element](https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/style)

## Related guides

- [Read a repository HTML document comfortably on iPhone](https://githtml.com/guides/read-repository-html-on-iphone)
- [Set a mobile viewport for an HTML report](https://githtml.com/guides/mobile-viewport-for-html-reports)
- [Add useful section navigation to a long HTML document](https://githtml.com/guides/table-of-contents-for-long-html)
- [Format code samples for reading on an iPhone](https://githtml.com/guides/code-blocks-for-iphone-reading)

Editorial approach: https://githtml.com/guides/about
