Broken Link Checker
A broken link checker fetches a page, collects every link and image on it, and requests each one to see what a visitor would actually get. Paste one page URL below: each fetchable link is checked and classified as OK, redirect, broken, server error, timeout or unreachable; links that must never be fetched — mailto:, tel: and in-page fragments — are listed but not requested; and anything resolving to a private or blocked address is reported as skipped, never fetched. One page per run, at most 300 links, and if a run stops early the partial result is labelled as partial — never presented as complete.
Last updated:
Limits, plainly: one page per run (this is not a whole-site crawl), at most 300 links checked per run, and a run can take up to about 25 seconds on a link-heavy page. This checker is limited to 5 runs per hour per address.
Link results
Dead links keep appearing between checks? Monitor this free with myeventwatch — expiry and downtime alerts, no card required.
What this checker does — and what it does not
When you submit a page, the checker fetches it once, parses the HTML, and collects the targets of its <a> links and <img> images, resolving relative URLs against the page’s final address after any redirect. Each unique web address is then requested in turn: redirects are followed and counted, so a link that works only after two hops is reported as a redirect with its hop count, not as a clean OK. The result is a per-link verdict with the final HTTP status code — the same evidence a browser, a search crawler or a frustrated visitor would meet when they click.
Three kinds of link are deliberately never fetched. Addresses with a non-web scheme — mailto:, tel:, javascript: and their kin — are not HTTP requests at all, so they are listed under “not fetched” with their reason instead of being faked into a status. Pure fragment links such as #section point inside a page the checker already has, so there is nothing new to request. And any link whose host resolves to a private, loopback or otherwise blocked address is reported as skipped: a public checker must never be usable as a lever into someone’s internal network, so those targets are named, counted and left strictly alone.
Reading the verdicts and fixing in the right order
Start with broken links that point inside your own site: a 404 on an internal link is a door you control that opens onto nothing, and fixing it — restoring the page, correcting the URL, or pointing the link at its replacement — helps every visitor and every crawler at once. Next come redirect chains: one redirect is normal after a move, but two or more hops slow every click and waste crawl effort, so update the link to the final address; the HTTP status chain tracer shows the full hop-by-hop path when you need to see it. Broken images come third — they rarely block reading, but they make a healthy page look abandoned. Timeouts and server errors deserve a re-check before surgery: a 5xx or a timeout can be one busy minute rather than a dead page, while a host that stays unreachable is a DNS or hosting problem, not a link problem.
This tool checks one page per run on purpose. A whole-site crawl is a different instrument — it belongs in your CMS reports, your server logs or Search Console — and pretending a single-page check covers a whole site would be dishonest. Run this checker against your homepage, your key landing pages, and any page you have just redesigned, migrated or pruned, and read the companion guide find broken links before your visitors do for when to check and in what order to fix. At most 300 links are checked per run; if a page carries more, or a run hits its time limit, the result says so and is labelled partial rather than silently truncated.
What each result status means
| OK | The link was fetched and the final response was a success (2xx) with no redirect needed — the visitor lands exactly where the link points. |
| Redirect | The link works, but only after one or more redirects (3xx). The count shows how many hops were followed to reach the final success. |
| Broken (4xx) | The server answered with a client error — most often 404 Not Found or 410 Gone. The page the link promises is not there. |
| Server error (5xx) | The target server failed to answer properly (500, 502, 503, 504 and kin). The link may be fine; the server is not — re-check before changing anything. |
| Timeout | The target did not respond within the checker’s time limit. Treat a single timeout as “slow or busy”, and a repeated one as a real problem. |
| Unreachable | No connection could be made at all — DNS failure, refused connection or a dead host. The address itself, not just one page on it, is in trouble. |
| Skipped (blocked) | The link resolves to a private, loopback or otherwise blocked address, so it was reported but never fetched. A public checker must not probe internal networks. |
Frequently asked questions
Does this checker crawl my whole website?
No. It checks exactly one page per run — the page you paste — plus every link and image on that page, up to 300 checked links. It does not follow links onward to crawl the rest of the site. For a whole-site view, use your CMS, your server logs or Search Console, and run this checker on the pages that matter most: the homepage, key landing pages, and anything recently redesigned or migrated.
Why are some links listed but marked “not fetched”?
Because fetching them would be meaningless or wrong. Links with a non-web scheme — mailto:, tel:, javascript: and similar — are not HTTP requests, so there is no status to report; fragment links (#section) point inside the page that was already fetched. Both kinds are listed with their reason so the accounting adds up: found links always equal checked links plus listed-but-not-fetched links plus any remainder a partial run did not reach.
Why did a link come back as skipped?
Its host resolves to a private, loopback or otherwise blocked address. A public link checker that fetched such targets could be used to probe internal networks — routers, admin panels, cloud metadata endpoints — so this checker reports those links as skipped and never requests them. If the link is on your own page and points at an internal address, that is usually a mistake worth fixing anyway: your visitors cannot reach it either.
The result is labelled partial. What happened?
The run stopped before every fetchable link was checked — the page carried more than the 300-link cap, or the run reached its time limit. The summary always shows how many links were checked out of how many were fetchable, and links missing from the table are un-checked, not healthy. Re-run the check to cover the same page again, and treat any verdicts you did get as valid: a broken link found in a partial run is still broken.
A link shows a server error but opens fine for me. Why?
Server errors and timeouts are often transient: the target was busy, restarting, or rate-limiting at the moment of the check, and fine a minute later. Re-run the check before changing a link that reports 5xx or timeout. If the same link fails repeatedly while opening fine in your browser, the difference is often geography, caching or bot handling at the target — the HTTP status chain tracer can show the exact response path the checker-style request takes.