Static Sites & Deployment

Absolute Path

Definition

There are two kinds of absolute reference on the web. A root-relative path begins with a single slash, as in /assets/style.css, and is resolved from the root of whatever host is currently serving the page. A fully qualified URL begins with a scheme, as in https://example.com/assets/style.css, and names the host as well. Both are absolute in the sense that matters: the page containing them could be at /, at /blog/, or at /docs/guides/deep/ and the browser would still request the same thing. That is exactly what you want for a site that always lives at the root of its own domain, and exactly what breaks when it does not. A relative path, by contrast, is resolved from the current document, which is why the two behave so differently after a move.

Why It Matters

The leading slash is the single most common cause of a site that works locally and breaks the moment it reaches static hosting. Open index.html from your desktop and /assets/style.css resolves to the root of your hard disk — on a Mac, literally /assets/style.css — which is not where your folder is, so the page loads unstyled. Publish that same folder under a sub-path, such as a preview at example.com/my-site/, and the browser asks for example.com/assets/style.css instead of example.com/my-site/assets/style.css, and every stylesheet, script and image 404s at once. Nothing about the upload is wrong; the references simply point somewhere that does not exist. One character on each reference is the entire bug, and a page with thirty assets fails thirty times over.

How It Works

When the browser meets a path beginning with a slash, it keeps the scheme and host of the current page and replaces everything after the host with that path. So on https://docs.example.com/guides/dns/, the reference /img/logo.png becomes https://docs.example.com/img/logo.png regardless of how deep the page is. A fully qualified URL skips even that step and is used verbatim, which is why it survives being copied into an email or an RSS feed but hard-codes the hostname into your files. That hostname matters later: build your site against a temporary address, then move it to a custom domain, and every absolute URL still points at the old one.

Real-World Example

A team builds a documentation site with every asset referenced as /css/docs.css and /js/search.js, and it is flawless on their build server, which serves it at the root. Published to 99helpers at acme-docs.99helpers.site it is also fine, because that address is a root too. The trouble starts when they share a chapter as a separate upload under its own name and reuse the same HTML: the paths still aim at the root of the new address, where no css folder exists, so the chapter arrives as unstyled text. Switching those two references to css/docs.css and js/search.js makes the same files work at either address.

Common Mistakes

  • Testing by double-clicking index.html — a file:// page resolves /assets/style.css against your disk root, so absolute paths fail there for a reason unrelated to the host
  • Hard-coding a full URL with the old hostname — after moving to a custom domain the site keeps loading assets from the previous address, or breaks when it is retired
  • Mixing an https page with absolute URLs written as http — browsers block the mixed content and the assets silently never arrive

Related Terms

Put a file online in seconds

Drop in a document, an image, a page or a whole static website and share the link — free, with no build step and no server to set up.

Host a file free →