Why does a link work on my laptop but 404 on the server?

Your development filesystem probably ignores filename capitalization, while the production server distinguishes Logo.PNG from logo.png. The deployed site may also use a different base path, routing configuration, or set of generated files. Check the exact URL, the deployed filename, and the production configuration.

Should I use absolute or relative paths for internal links?

Let your CMS or framework generate them whenever possible. Hard-coded URLs containing a development or staging domain are fragile, and deep ../ chains break when pages move. Root-relative URLs like /images/logo.png work well for a site permanently hosted at the domain root; an application that may be deployed under a path prefix should build URLs from a configured base path.

How do I catch broken links before visitors do?

Crawl the built or staging site before release, then crawl the live site after deployment. Check links, images, scripts, stylesheets, downloads, redirects and form targets — not only the homepage. The first pass catches mistakes early; the second verifies the real server and configuration.

Do your links and file paths survive deployment?

A link that works perfectly on your laptop can be dead the moment it reaches the server. The hostname in a URL is case-insensitive — Example.COM and example.com reach the same place — but the path after it should never be assumed to be: a link to /Photos/Logo.PNG can work all through development and return a 404 in production, where the real path is /photos/logo.png.

Three different rules

The confusion comes from three layers that each behave differently:

Domain names are case-insensitive, by definition.
URL paths should be treated as case-sensitive. Whether /Photos/ and /photos/ really differ depends on what handles the request — static files on a typical Linux host are case-sensitive, while a CMS or framework may normalize or route paths by its own rules.
Filesystems vary by operating system: most Windows and macOS development machines ignore case by default; the Linux servers behind most hosting do not.

Don't rely on a forgiving development environment or a forgiving CMS. Use one consistent lowercase form for public URLs, directories and filenames — team-photo.webp, never Team Photo.WEBP — and prefer letters, numbers and hyphens: spaces and special characters need URL encoding and are easy to mishandle in links and scripts.

The case-only rename trap

On a case-insensitive development machine, renaming Logo.PNG to logo.png changes nothing the system can see — so version control and deployment tools may never record it, and the server keeps the old name. Rename through a temporary name so the change is real:

git mv Logo.PNG logo-temp.png
git mv logo-temp.png logo.png

Then check the deployed server holds only the correctly cased file.

Paths that break when things move

Even with the right casing, links break when the address they assume changes:

Hard-coded absolute URLs (https://localhost/... or a staging domain) ship straight into production pointing at the wrong place.
Fragile relative paths (../../assets/...) break the instant a page moves to a different folder depth.
Root-relative paths (/images/logo.png) are robust for a site that permanently lives at the domain root — and fail if the same application is later served under a prefix like /shop/. Reusable applications should build URLs from a configured base path; a business site fixed at the root can use root-relative paths with a clear conscience.
Missing build output — a generated CSS, script or image that exists locally but is excluded from version control or skipped by the deployment.
Trailing slashes — /products and /products/ may be one resource, a redirect, or two different routes. Pick one canonical form and redirect the other consistently.

And when mixed-case URLs were already published: choose the canonical lowercase URL and 301-redirect the old variants to it — enforced centrally in the server or application, not as a pile of hand-written rules — rather than letting several capitalizations answer 200 OK as duplicates.

Test before and after deploy

Loading the homepage once proves nothing. Crawl the built or staging site before release, then crawl the live site after deployment — links, images, stylesheets, scripts, downloads, redirects and form targets — because only production has the real filesystem, routing and configuration.

Takeaway: The server forgives the hostname's case but little else — keep paths consistently lowercase, let configuration build your URLs, rename with care, and verify the real links on the live site every time you deploy.

What to do

Adopt an all-lowercase convention for every filename, folder, and URL slug — letters, numbers and hyphens only.
Let the framework or CMS generate URLs, with environment-specific base paths in configuration, not hard-coded.
Rename case-only changes through a temporary name so version control and deployment actually pick them up.
Serve one canonical form — redirect mixed-case and trailing-slash variants centrally instead of letting duplicates return 200.
Crawl the built site before release and the live site after deploy, covering assets and redirects, not just links.