Why "Save as HTML" from Word is the wrong tool

Word's own Save as Web Page was built to round-trip back into Word, not to publish. So it embeds everything it might need to reopen the file: Office-specific style blocks, conditional comments, VML fallbacks. Your <h1> becomes a styled <p> with a hardcoded font. Drop that into a modern site and it fights your stylesheet; drop it into an email and half the clients mangle it.

What you actually want is the structure — headings as headings, lists as lists, links as links — and none of the styling, because your site or email template already owns the look.

The clean-output approach

A good converter throws away everything Office-specific and keeps only semantic tags. A heading becomes an <h2>, a bulleted list becomes a real <ul>, bold becomes <strong>, and the mso- soup simply doesn't make it into the output. That's the job of a Word to clean HTML converter: same words, same structure, markup you can actually read and style.

If you're working from a live Google Doc rather than a .docx, the same idea applies — copy the content and run it through a Google Docs to HTML converter, and the c1/c17 class soup Docs loves to emit gets stripped down to plain tags.

Tables and images, the two things people get burned by

• Tables: a real converter emits a proper <table> with <th> and <td>, not a grid of positioned divs. Merged cells are the one genuine limitation — HTML supports them, but they don't always survive a document's messy internal representation, so check anything with a complex header.

• Images: decide up front whether you want them inlined as base64 (one self-contained file) or pulled out as separate assets. Base64 is convenient for a single email; separate files are better for a page you'll maintain.

Don't upload the document to do it

Most "doc to HTML" sites upload your file to a server to convert it. For a blog draft, whatever. For a client proposal, an internal memo, or an unpublished press release, that's a copy of a confidential document sitting on someone else's machine — to save a couple of minutes.

The conversion doesn't need a server. A browser can parse the document and emit HTML locally, with nothing leaving the tab. docs2html works that way — open the network panel and you'll see it stays silent, and it keeps working with your Wi-Fi off. If your target format is Markdown instead of HTML (for a README or a wiki), its sibling docs to Markdown tool does the same thing locally.

The short version

1. Never publish Word's "Save as HTML" output — it's built to reopen in Word, not to ship.

2. Use a converter that keeps semantic tags and drops mso- styles and class soup.

3. Check tables with merged cells and decide how images should travel.

4. Prefer a local, no-upload tool for anything confidential.

Clean HTML pastes into any CMS, survives email clients, and matches your own stylesheet instead of overriding it. It's the difference between content you can maintain and a block you're afraid to touch.

Option 1: The built-in export (okay, but lossy)

Google Docs has File → Download → Markdown (.md) now. It works for simple documents, but it stumbles on the things you actually care about: nested lists flatten, tables come out inconsistent, and anything you pasted in with odd formatting carries that baggage into the output. For a quick note it's fine. For anything structured, you'll be cleaning up by hand.

Option 2: Copy, then paste as Markdown (fastest)

The trick most people miss: your clipboard already carries the document's structure as rich HTML. If you select the content in the doc, copy it, and paste it into a converter that reads that rich clipboard, the headings, bold, links, and lists survive — because it's converting the structure, not a screenshot of the text.

That's the workflow I use now: select all in the Google Doc, copy, and paste it straight into the converter as Markdown. Headings become ##, bold stays **bold**, links keep their targets, and lists keep their nesting. It takes about three seconds and there's nothing to clean up.

Option 3: Convert the file (for .docx exports)

If what you have is a downloaded .docx instead of a live doc, drop it into a Google Docs to Markdown converter and it'll do the same job on the file. Same clean output, no manual fixups.

Why "without uploading" matters here

Most online converters work by uploading your file to a server, converting it there, and sending the result back. For a throwaway note that's no big deal. For a contract draft, an internal spec, an unpublished article, or anything with a client's name in it, you've just handed a copy to a third party you know nothing about — to save yourself thirty seconds of formatting.

It doesn't have to work that way. Modern browsers can do the whole conversion locally: the document is read, parsed, and turned into Markdown in the browser tab, and nothing is ever sent anywhere. That's the approach docstomd takes — you can watch the network tab, it stays quiet. It even works offline once the page has loaded.

A few things Markdown can't hold

Set expectations before you convert, so you're not surprised:

• Fonts and colors don't survive — Markdown is plain text, and that's the point. Styling is the renderer's job.

• Merged table cells have no equivalent; Markdown tables are strictly rectangular.

• Comments and suggestions aren't content, so they're dropped.

Everything structural — headings, lists, links, bold, italics, code, blockquotes, plain tables — comes across cleanly.

If you need HTML instead

Sometimes the target isn't Markdown but clean HTML — for an email, a CMS, or a page. Same idea, different output: a local Google-Docs-to-HTML converter gives you semantic <h2> and <p> tags without the mso- style soup Word and Docs usually leave behind.

The short version

1. Select the content in your Google Doc and copy it.

2. Paste it into a converter that reads the rich clipboard — structure survives.

3. Prefer one that converts locally, so the document never leaves your machine.

4. Don't expect fonts, colors, or merged cells — Markdown keeps structure, not styling.

Once it's Markdown, it drops straight into Git, a static site, or a wiki and stays diff-able forever. That's the whole reason to get out of the word processor in the first place.

Most "free online converters" work like this: you pick a file, it's uploaded to a server, converted there, and sent back. That's fine for a meme. It's less fine for a folder of personal photos, a passport scan, or client footage under NDA.

I built VisualRefiner to do the same jobs without the upload. Every conversion runs in the browser tab on your own machine. There is no backend to send files to — the whole site is a static export — so "your files never leave your device" isn't a privacy promise, it's just how the architecture works. Here's the interesting part of how it's put together.

The core: <canvas> is a format converter

The humble 2D canvas is already an image transcoder. Decode any image the browser understands into an ImageBitmap, draw it, and re-encode with toBlob() — the MIME type you pass decides the output format:

async function convert(file, type = "image/jpeg", quality = 0.82) {
  const bitmap = await createImageBitmap(file);
  const canvas = document.createElement("canvas");
  canvas.width = bitmap.width;
  canvas.height = bitmap.height;
  canvas.getContext("2d", { alpha: true }).drawImage(bitmap, 0, 0);
  bitmap.close();

  return new Promise((resolve, reject) =>
    canvas.toBlob(
      (blob) => (blob ? resolve(blob) : reject(new Error("encode failed"))),
      type,           // "image/jpeg" | "image/png" | "image/webp"
      quality,        // ignored for PNG (lossless)
    ),
  );
}

That single function is PNG↔JPG↔WebP conversion and JPG/WebP compression (the quality argument) all at once. No dependency, no upload, works offline. The result is a Blob; wrap it in URL.createObjectURL() for a preview or a download link.

Two details that bite you if you skip them:

• Revoke your object URLs. Each createObjectURL pins the blob in memory until you URL.revokeObjectURL() it. In a tool people use repeatedly, forgetting this is a slow leak. Revoke the previous URL every time you produce a new one.

• PNG ignores quality. A "quality slider" on a PNG export does nothing — PNG is lossless. Hide the control or convert to WebP if the user wants a smaller file with a quality knob.

HEIC: the format the canvas can't read

Then there's HEIC — the format iPhones save by default. Most browsers won't decode it in a <canvas> pipeline, so createImageBitmap() throws. The fix is to decode it ourselves first, with libheif compiled to WebAssembly (via heic2any):

async function normalize(file, quality) {
  const isHeic = /heic|heif/i.test(file.type) || /\.hei[cf]$/i.test(file.name);
  if (!isHeic) return file;

  // Only pulled in when someone actually hands us a HEIC file.
  const { default: heic2any } = await import("heic2any");
  const out = await heic2any({ blob: file, toType: "image/jpeg", quality });
  return Array.isArray(out) ? out[0] : out;
}

Now HEIC flows into the same canvas function as everything else. The WASM decoder is the heaviest thing on the site (~2 MB), which brings up the next point.

Load the heavy parts lazily

If you bundle libheif, a video engine, and a GIF encoder into your main chunk, your homepage pays for tools the visitor may never touch. The trick is a dynamic import() at the moment of use — note the await import(...) inside both functions above and below. The bundler splits each into its own chunk, and the network tab confirms the 2 MB HEIC decoder only downloads when someone converts a HEIC file. The homepage ships a small bundle; the weight arrives on demand.

High-quality resizing is the same story. Canvas drawImage downscaling aliases badly (jagged edges, moiré). pica does proper Lanczos-style resampling, so it's loaded only on the resize path:

if (needsResize) {
  const { default: pica } = await import("pica");
  await pica().resize(sourceCanvas, targetCanvas);
}

Video, without FFmpeg-in-WASM

Video is where people reach for ffmpeg.wasm, but it's a big download and slow. Modern browsers expose WebCodecs — hardware-accelerated encode/decode built into the browser. VisualRefiner drives it through mediabunny to transcode clips to MP4 or WebM, extract frames as PNG, or build a GIF (with gifenc) — all in the tab.

The honest caveat: WebCodecs support and the available codecs depend on the browser. So conversion isn't guaranteed for every exotic input the way the canvas image path is. The tool checks and tells you when a track can't be decoded, rather than pretending. That trade — depend on the platform, degrade honestly — beats shipping a 25 MB WASM FFmpeg to every visitor.

Why static export makes the privacy claim trivially true

The site is a Next.js app exported to static files (output: "export") and served as plain assets from a CDN. There is no API route, no server that receives a file, nothing to log. You don't have to trust a privacy policy — open DevTools → Network, convert something, and watch: zero upload requests. The bytes stay in the tab.

That also means the "server cost" of a converter that could handle thousands of files is… a static host. All the compute is the user's.

Takeaways

• <canvas> + toBlob() is a complete image converter/compressor with zero deps.

• For formats the browser can't decode (HEIC), a WASM decoder bridges the gap — load it lazily so everyone else doesn't pay for it.

• Prefer WebCodecs over WASM FFmpeg for video when you can accept browser-dependent codec support.

• Dynamic import() per feature keeps the initial bundle small.

• A static export turns "we don't upload your files" from a promise into an architectural fact.

If you want to see it in action, the tools are at visualrefiner.com — HEIC → JPG, image compressor, video to GIF — and the code is on GitHub.