Broken Links Checker Free Tool

Enter a URL

About Broken Links Checker

What This Tool Actually Does

Paste one page URL into the box above, submit it, and this tool crawls that single page's HTML, pulls out every link it finds, and checks each one live to see whether it still works. It splits the results into two tables: links pointing to the same site (internal) and links pointing elsewhere (external). That split lets you see at a glance whether the problem sits on your own pages or in something you linked out to.

That's the whole job, and it's worth being precise about it because "broken link checker" gets used as a label for a few genuinely different tools. This one is not a whole-site crawler. It doesn't discover other pages on your domain and check them too; it only looks at the one URL you submit. It's also not a bulk list checker. You're not pasting fifty URLs you already have and asking for a status report on each of them; this tool reads a page's markup and builds its own list of links from what it finds there. If you already have a list of URLs to check, this site runs a separate tool built for exactly that (more on the difference later in this page). If this tool is a good fit for what you're trying to do, keep reading. The mechanics below are described exactly as the code behind this page runs them, not as a generic explanation of how broken-link checkers work in the abstract.

That last point matters more than it might sound. A lot of "how broken link checkers work" content online is written generically enough to apply to any tool with that name, which means it often gets specifics wrong for any one particular tool, including this one. Everything below, including the parts that describe a real limitation in how this tool grades its own results, was confirmed directly against the code that runs this page, not assumed from the tool's name or from how a typical checker is usually built.

How the Scan Works, Step by Step

Here's what happens between you clicking submit and the results table appearing, described accurately rather than as a black box.

1. The page is fetched. The tool requests the raw HTML of the URL you submitted, the same way a basic crawler would: it reads the markup as delivered by the server, before any client-side JavaScript runs. If a page builds part of its navigation or content with JavaScript after the initial load, links added that way won't be in the HTML this tool sees, so they won't show up in either results table. This isn't a bug specific to this tool; it's a limitation shared by any checker that reads raw HTML instead of running a full browser.
2. Every anchor link is extracted. The tool looks specifically at <a href> tags. It does not check images, embedded scripts, stylesheets, or other resource references, only actual hyperlinks. If a page's broken references are mostly missing images rather than dead links, this tool won't catch those; it's scoped to link checking, not a general resource-integrity scan.
3. Duplicate links are collapsed. If the same exact link URL appears more than once on the page, say a "Read more" link and a matching headline link both pointing to the same article, it's only queued for checking once, so you won't see the same URL tested twice in the results.
4. Each link is classified as internal or external. A link is treated as internal if it points to the same host as the page you submitted, or if it's a relative path (starting with /) that implicitly belongs to that same site. Anything pointing to a different domain is external. This classification decides which of the two results tables the link ends up in.
5. Each link is checked live, one at a time. The tool sends a lightweight request to every link's destination, the kind of request that asks "are you there and what do you return?" without downloading the full page content, which keeps the check fast. There's a 30-second window for each individual link to respond before it's treated as unreachable.
6. Nothing is cached. Every submission is a fresh, live check of every link on the page, not a lookup against a saved result from an earlier scan. That's a deliberate tradeoff on this tool specifically (see the comparison section further down): it means results are always current, at the cost of a slower scan on pages with a lot of links.

There's no fixed limit on how many links a single scan will attempt to check. The tool works through everything it finds on the page. The practical ceiling is a generous script execution window on the server side (measured in minutes, not seconds), which exists to stop a single request from running forever rather than to cap how thorough the scan can be. In plain terms: a normal blog post or landing page with a few dozen links checks in well under a minute. A page with an unusually large number of external links, especially to slow-responding servers, will simply take longer while each one gets its full chance to respond before the tool moves on to the next.

How to Use This Tool

1. Open the page you want to check. Pick the specific URL you want audited: your homepage, a landing page, a specific blog post, or any single page whose links you want verified.
2. Paste the full URL into the input box above. Include the protocol (https://) or the tool will add http:// automatically if you leave it off; for accuracy, paste the exact URL including https:// if that's how the page is actually served.
3. Submit the form. The page will show a brief processing indicator while the scan runs in the background.
4. Wait for the scan to finish. How long this takes depends entirely on how many links are on the page and how quickly each destination responds. A small page finishes in seconds; a link-heavy page can take noticeably longer since every single link gets checked live, one after another.
5. Review the Internal Links table first. These are links within your own control, and anything flagged there is the fastest, highest-value fix available to you.
6. Review the External Links table next. These point off-site, so a "broken" result here often means something changed on someone else's server, not yours. Verify manually before assuming the worst (see the label-limitation section below before you trust the results at face value).
7. Fix what's genuinely broken, then re-run the scan. Update, redirect, or remove each confirmed dead link, then submit the same URL again to confirm the fix actually resolved it.

Reading Your Results: Internal vs. External Links Tables

After a scan completes, you'll see two separate tables rather than one merged list, and understanding why they're split helps you prioritize.

Each table lists three things for every link found: the URL itself, the HTTP status code returned when it was checked, and a plain-text status next to it. That third column is where the nuance lives, and it's worth reading the next section carefully before you act on it.

The One Thing to Know Before You Trust the "Broken Link" Label

This is the single most important thing to understand about how this specific tool grades its results, and it's based on how the underlying check is actually built rather than how you might reasonably assume it works.

Only a link that comes back with an exact 404 response gets labeled "Broken Link" in the results table. Every other outcome, a server error, a request that times out with no response at all, or a link caught mid-redirect, is still labeled with the same word used for a genuinely working link. The status-code column next to it will show something other than 200, which is your real signal, but the plain-text label itself won't flag it as a problem. In practice this means: don't trust the label alone. Glance at the actual status code in the middle column for every row, especially any row that isn't a clean 200 or a clean 404, because the label won't tell you it needs attention.

Picture a page with a link to an external resource that's actually gone. If the destination server simply refuses to respond and the request times out, the code column will show the "Unknown" placeholder rather than a number, and the label next to it will still read "Okay." A reader skimming for anything marked "Broken Link" would walk right past that row and never know the link needs fixing. That's the exact scenario this section is warning you about, not a hypothetical edge case.

There's a second, related nuance worth knowing if a page you're checking uses a lot of redirects. When a link redirects, say, an old URL that 301s to its new address, this tool's check follows that redirect to see what's on the other end, but the result it records is based on the very first response the link produced, not necessarily the final page you'd land on after every hop. Concretely: if a link 301-redirects to a page that itself no longer exists, the result you'll see reflects that initial redirect step rather than the dead end at the far side of it. If a page you're auditing relies heavily on redirects, common after a URL structure change or domain migration, treat any non-200, non-404 result as worth a manual click-through rather than assuming it's fine just because it isn't red.

None of this makes the tool less useful. A clean, uncomplicated 404 is still exactly what most broken links actually are, and those get flagged correctly and immediately. It just means the safest habit is: scan the status-code column for anything other than 200, not just the word next to it.

HTTP Status Codes at a Glance

For context, here's what the status codes you'll see in either results table generally mean, independent of how this particular tool labels them.

This table is general HTTP knowledge, true of any web request anywhere. It's not describing how this tool's own "Broken Link" vs. "Okay" label is assigned, which was covered in the previous section and works differently: only 404 triggers the "Broken Link" text, as explained above.

Why Broken Links Hurt SEO and User Experience

Broken links create two separate problems worth separating, because the fix and the urgency differ for each one.

Wasted crawl budget on dead ends

Search engine crawlers follow links to discover and re-visit pages. Every internal link on your site that leads to a 404, the kind of result you'd see clearly flagged in this tool's Internal Links table, is a dead end a crawler spends time on instead of your actual content. On larger sites with a lot of pages, that adds up. On smaller sites it matters less in raw volume, but it still means link equity isn't flowing where you want it.

A poor experience for real visitors

A visitor who clicks a link inside your own article and lands on a 404 page forms an immediate impression that the site isn't well maintained. If that link was in the Internal Links table of a scan you ran, it's a fully avoidable bad experience, and the fix is entirely within your own control.

Lost internal link equity when the dead link is your own

When an internal link points at a page you've since deleted or moved without a redirect, whatever authority and relevance signal was flowing to that old page through the link is effectively going nowhere. This is exactly the kind of result that shows up as a 404 in the Internal Links table after a scan of an older post: a page that used to link to a resource page you retired months ago, and nobody went back to update the reference.

Common Causes of Broken Links

Broken links rarely appear all at once. They accumulate quietly over months as content changes, and a periodic scan is the only realistic way to catch the drift before it becomes a large cleanup project. The usual culprits fall into a handful of recurring patterns.

• Pages deleted without a redirect. Content gets removed, reorganized, or replaced, and the old URL is never redirected to its new home. This is the single most common cause of a 404 showing up in the Internal Links table on an older page.
• External sites restructuring or going offline entirely. A source you linked to years ago changes its own URL structure, gets acquired and merged into a different domain, or simply shuts down. None of that is something you control, and it's exactly what shows up as a broken result in the External Links table.
• Typos in manually-typed URLs. A link typed by hand into an editor, especially a long one, is an easy place for a stray character or a dropped letter to slip in. The link looks plausible at a glance but points nowhere real.
• Site migrations that miss some old paths. Moving to a new CMS, changing your URL structure, or switching domains often redirects the pages someone remembered to map, and quietly misses the long tail of older internal links buried in older content.
• Domain expiration on a linked external site. An outbound link can go dead not because the specific page was removed, but because the whole domain it lived on lapsed or was never renewed. This usually shows up as a no-response or connection-level failure rather than a clean 404, since there's no server left to answer the request at all.

Limitations to Keep in Mind

Every automated link checker has blind spots, and knowing where this one's are helps you read a results table correctly instead of over-trusting or under-trusting it.

• Login-gated or paywalled destinations. A link to a page that requires an account to view can come back as an error or a login redirect even though the resource itself is perfectly fine. This can look like a false positive if you don't recognize the destination as something that requires authentication.
• Sites that block automated requests. Some destinations rate-limit or block traffic that doesn't look like a normal browser visit, which can return an access-denied or error response to this tool's check even though a person clicking the same link in their own browser lands on a working page without issue.
• A single-scan snapshot, not ongoing monitoring. Results reflect the exact moment the scan ran. A link flagged with an error because the destination server was briefly overloaded might work again minutes later, and a link that's clean today can break tomorrow with no warning. A one-time scan tells you about right now, not about next month.
• One page at a time, not the whole site. As covered above, this scans exactly the URL you submit. Auditing a full site means running the check page by page, prioritizing the pages that matter most rather than trying to cover everything in one pass.
• A working redirect isn't automatically a problem. Not every non-200 result is something to fix. A clean 301 that leads somewhere genuinely useful is often fine left as-is. The point of reading the status-code column carefully is to separate that from a redirect that dead-ends, not to treat every non-200 as an emergency.

Broken Links Checker vs. the Cached Bulk-List Checker

This site also runs a second, separate tool built for a genuinely different starting point: Broken Link Checker (Cached). The difference is in what you give it and how it checks each link, not just a naming coincidence.

If you're auditing a single page and want to know what's linked from it, this page is the right tool. If you're maintaining a running list of URLs, a set of affiliate links, a resource list you track separately, or a backlog from a previous audit, the cached list-based tool is built for that use case instead. Neither tool is a strict upgrade over the other; they're built for different starting points, and picking the right one saves you from reshaping your workflow around the wrong tool's input format.

How to Fix Broken Links Once You Find Them

• Update the link to the correct current URL if the content simply moved rather than disappeared. This is the cleanest fix and preserves the original intent of the link.
• Redirect the old destination to a live equivalent if you control the target page and it was removed in favor of something similar. This fixes the link for every page that references the old URL, not just the one you scanned.
• Remove the link entirely if nothing equivalent exists anymore and there's no reasonable replacement. A dead reference is worse than no reference at all.
• Use an archived version as a last resort for an external source that's genuinely gone for good but whose original content still has citation value. The Wayback Machine is the standard fallback when nothing live replaces it.
• Re-run the scan after fixing anything to confirm the change actually took effect, rather than assuming it did.

Best Practices for Using This Tool Effectively

• Start with your highest-value pages. Your homepage, top landing pages, and best-performing content see the most traffic. A broken link there costs more real visitors than the same broken link buried in a page nobody visits.
• Re-scan right after any migration or redesign. A change in URL structure, a CMS switch, or a domain move is the single most common trigger for a sudden batch of new internal 404s. Checking your key pages immediately after catches the damage before it sits unnoticed for months.
• Give a single flagged error the benefit of the doubt, then verify. A server error or a timeout on one scan can be a temporary blip on the destination's end. Re-run the check, or open the link manually in a browser, before deciding it's genuinely dead, especially for external links, where you have no visibility into what's happening on the other server.
• Handle internal links before external ones. Internal broken links are entirely within your control and directly affect your own crawl efficiency and visitor navigation. Fix those first, then work through anything external.
• Keep a record of what you remove and why. If a broken external link pointed at a genuinely valuable source, check whether an archived copy exists before deleting the reference outright. The citation value of the source may still be worth preserving even if the live link is gone.

Related Tools

• Redirect Chain Checker: if a link in your results comes back mid-redirect, this tool traces the full hop-by-hop chain to its actual final destination, which is exactly the follow-through this broken-links checker doesn't do on its own (see the label-limitation section above).
• Orphan Page Finder: a different angle on internal-link health. Instead of finding links that go nowhere, it finds pages on your site that nothing links to at all.
• Fast Backlink Indexer: once your own links are clean, this tool helps get your outbound-facing backlinks discovered and indexed faster.

A Realistic Example: Auditing a Single Blog Post

Say you're auditing an older blog post that's been live for a couple of years. You paste its URL in, submit, and a minute later you have two tables in front of you.

The Internal Links table shows a link to a resource page you retired six months ago when you consolidated two similar pages into one. It comes back as a clean 404, correctly labeled "Broken Link." That's an easy, fully-controllable fix: update the link to point at the surviving page, or redirect the old URL server-side so every other post referencing it gets fixed at once instead of just this one.

The External Links table shows a link to a source you cited years ago. The status code column shows nothing but the "Unknown" placeholder, and the label still reads "Okay," exactly the scenario described earlier in this page. A quick manual check in your browser confirms the domain no longer resolves at all: the site is genuinely gone, not just slow. Since there's no live equivalent, the practical fix is either to remove the citation or replace it with an archived copy of the original page if the source itself still has value.

That's the pattern worth internalizing: treat the Internal Links table as your priority list, and treat the External Links table as a set of leads that need a second look rather than a final verdict, particularly for any row that isn't a plain 200 or a plain 404.

Frequently Asked Questions

Does this tool check my whole website or just one page?

Just the one page URL you submit. It extracts and checks every link found in that page's HTML; it doesn't crawl to other pages on your site automatically. To audit more pages, run the scan again on each URL you want covered, starting with your highest-traffic and highest-priority pages.

Why does a link show as "Okay" when I can see it's clearly broken?

Because this tool's "Broken Link" label is only triggered by an exact 404 response. See "The One Thing to Know Before You Trust the 'Broken Link' Label" above. A server error, a timeout, or a link caught mid-redirect will still show "Okay" next to it, even though the status code in the middle column tells a different story. Always check the actual code, not just the label.

Does it check images or only text links?

Only actual hyperlinks, meaning anchor tags. It does not check images, scripts, stylesheets, or other embedded resources, so a broken image on a page won't be caught by this scan even though a broken link right next to it would be.

Can it check links that JavaScript adds to the page?

No. The tool reads the page's raw HTML as delivered by the server, before any client-side JavaScript runs. If your navigation or content injects links dynamically after the page loads, those links won't be in what this tool sees.

What's the difference between this tool and the Cached Broken Link Checker on this site?

This tool crawls one page you give it and finds its links automatically, with no caching; every scan is fresh. The cached tool works from a list of URLs you already have, checks exactly those, and caches results to speed up repeat checks. See the comparison table above for the full picture.

How often should I re-check a page's links?

There's no fixed rule, but a quarterly check is reasonable for most pages, and more frequent checks make sense for pages that link out heavily to external sources, since those are the links most likely to break without any change on your own site.

Should I remove a flagged link right away, or wait to see if it comes back?

For a clean, confirmed 404 on an internal link, it's safe to fix or remove it immediately; that result is reliable. For anything else, especially on an external link where the status code shows a server error, a timeout, or an access-denied response, it's worth a manual check or a second scan a day later before deciding it's permanently gone, since those outcomes can be temporary or specific to automated requests rather than a true dead end.