{{ summaryTitle }}
{{ summaryValue }}

{{ summaryLine }}

Observed{{ checkedCount }} Untested{{ resultsReady ? computation.values.counts.untested : '—' }} Inconclusive{{ resultsReady ? computation.values.counts.inconclusive : '—' }}
Fetch one public HTML page up to 512 KiB. URLs are sent only when you act; keep private or signed URLs out.

{{ notice }}

{{ provenanceLabel }}. {{ computation.values.retained }} unique links retained; {{ selectedCount }} selected, maximum 20 per request.

Inventory cap reached: {{ computation.values.omitted }} additional unique links are omitted and untested. Only the first 100 are retained.

Limit “Select next 20 untested” to the resolution base origin. All retained findings remain visible.

The coverage chart is unavailable. Link findings retain every outcome.

{{ resolutionNotes }}

Similar tools

A renamed guide can leave an old address behind in a menu, a help article, or a partner directory. Broken-link checking connects those references to the responses from their destinations, giving editors a starting point for repairs. It is useful after a site move, before publishing a resource list, and when older pages still send readers to retired content.

The words readers click are the anchor text. The destination is stored separately in the link's href attribute, so a sensible label can conceal an outdated address. Internal links usually point into the site being maintained, while external links depend on another publisher's pages and access rules. Both can fail even when the referring page itself loads normally.

Absolute address
A complete URL identifies its own destination, including the protocol and host.
Relative address
A value such as guide.html needs a base URL before it identifies a destination. Moving the referring page or changing its base can change where the same text leads.
Fragment
The part after # usually identifies a location within a document. A successful response for the document does not establish that the named section exists.

A redirect can keep an old address useful by sending the request to a new location. The important question is where that chain ends and whether the final page still serves the intended purpose. A removed document, a sign-in requirement, a request limit, and a temporary server failure call for different decisions. Treating every unsuccessful response as a deleted page can lead to removing links that readers still need.

Repeated links also need careful counting. A navigation menu and several paragraphs may all point to the same destination, while two section links may request the same document with different fragments. Checking the destination once can cover its HTTP response, but an editor may still need to change several occurrences or inspect individual section targets.

Automated checks record how a destination responds from a particular location, using a particular request method, at that time. A signed-in visitor may see content that an unauthenticated checker cannot access. Conversely, an error message or login screen can arrive with a successful HTTP response. Response evidence helps prioritize repairs; it does not verify the meaning or safety of the returned content.

Coverage matters as much as the error count. Inspecting links present in one page's HTML leaves other pages and links created later by JavaScript outside that inspection. A useful maintenance report makes that boundary clear and distinguishes destinations that were checked from those still awaiting a request.

How to Use This Tool:

Work with one public source page at a time. Retrieving its HTML, extracting its links, and checking selected destinations are separate stages.

  1. Enter the address in Public page URL, replacing the initial example address. Include http:// or https:// and omit embedded usernames, passwords, or sensitive query values. An invalid-URL message requires correcting this field before fetching.
    Load example page creates a local demonstration inventory without fetching a page. Its destinations remain untested until you explicitly check them, which makes real public requests.
  2. Select Fetch page. An accepted page produces a link inventory without testing outgoing destinations. If the source is rejected, read the stated HTTP, content-type, size, partial-content, or encoding problem and correct the source or choose a suitable page before retrying.
  3. Choose the links to check. The first 20 retained destinations, or all destinations when fewer exist, are initially selected. Use the checkboxes or Clear selection to review the actual batch before sending it.
    Same origin only in Advanced limits only Select next 20 untested. It uses the resolution base's protocol, host, and port. It does not change the initial or current selection, hide external findings, or prevent manually checking external links.
  4. Select Check selected links to request observations for that batch. Read each Outcome together with its Final status and Method and raw evidence. A finished batch can still contain inconclusive results.
    If the batch exceeds the 64 KiB request limit, select fewer links. After a request error, Retry request repeats the last operation using the current URL or selected links.
  5. Use Select next 20 untested to prepare another batch, then check it explicitly. This shortcut leaves inconclusive destinations out, so select those manually when a deliberate recheck is appropriate.

Interpreting Results:

Observed counts retained destinations with an observation, including inconclusive attempts. It does not mean all those destinations were reached successfully. A 0 broken summary can coexist with untested links, restrictions, throttling, server failures, or inconclusive evidence.

  • Broken identifies a response reporting that the destination was not found or is gone. Review the original address and its occurrence count, then confirm the intended replacement before editing the referring page. A 404 does not prove permanent deletion and can also conceal a restricted resource.
  • Restricted, Throttled, and Server failure call for checking access rules, waiting before retrying, or investigating the destination server. They are not interchangeable with a missing page.
  • Inconclusive requires reading the reason and available request evidence. A timeout, name-resolution problem, certificate failure, or unfinished redirect does not establish that the address is broken.
  • Reachable means the recorded final HTTP response was successful. Review the Final URL when redirects occurred and inspect the content when its purpose matters. Section targets, misleading success pages, and destination safety need separate checks.

Outcome coverage counts retained unique destinations, rather than every anchor occurrence or every link on the site. Additional unique links omitted by the inventory cap are outside those counts. A No links result establishes no outgoing-link status coverage. Resolution notes preserve the source attribution and the retained, omitted, duplicate, and skipped counts needed to explain that scope.

For evidence that will be processed again, JSON retains the findings, source context, counts, and recorded request evidence. CSV and copied rows add an apostrophe before formula-like cells beginning with =, +, -, or @, including after leading spaces, tabs, or line breaks. That spreadsheet precaution changes the exported text. JSON retains the raw finding values without this prefix. DOCX preserves the displayed table text, including its empty-value labels and dashes, without the CSV prefix. Neither format restores anchor text already shortened during extraction.

Technical Details:

An HTTP status describes the response to a request for a resolved address. Reliable interpretation requires both a final status and enough evidence that the request reached a conclusion. Extracting an address from HTML provides no status evidence by itself.

Rule Core

Classification checks completeness before interpreting the status code. An error, a reported request limit, or a missing or empty response chain makes an observation inconclusive, even when it also contains a final code of 200. Otherwise, the following rules apply.

Outcome Required evidence
Untested No observation exists for the retained destination.
Reachable A complete observation ends with HTTP 200 to 299, inclusive.
Broken A complete observation ends with HTTP 404 or 410.
Restricted A complete observation ends with HTTP 401 or 403.
Throttled A complete observation ends with HTTP 429.
Server failure A complete observation ends with HTTP 500 to 599, inclusive.
Inconclusive Evidence is incomplete, an error or limit is reported, or the final status is outside the classes above. Remaining redirects and other 4xx responses belong here.

A redirect followed by a completed successful response is reachable. A redirect without a conclusive ending remains inconclusive. The final outcome therefore depends on the whole recorded attempt, rather than the first response in the chain.

Address resolution and duplicate occurrences

The source URL is the address submitted for retrieval. The effective URL is the response address after source redirects. The resolution base turns relative link addresses into full URLs and can differ from both.

  1. Read anchor elements with an href attribute from the returned HTML without rendering the page or running its scripts. Extraction does not load images, frames, or stylesheets. Their addresses, form actions, and links created later by JavaScript are outside this inventory. Destination pages are not recursively inspected.
  2. Resolve each declared <base href> against the effective URL. Use the first declaration that produces an HTTP or HTTPS URL without embedded credentials. If none qualifies, use the effective URL.
  3. Resolve each anchor address against that base. Keep HTTP and HTTPS addresses without embedded credentials, while skipping unsupported schemes such as mailto:, tel:, and javascript:, malformed addresses, and addresses over the length limit.
  4. Remove the fragment and group identical resolved URLs. Keep the first occurrence's original attribute value and anchor text, count every occurrence, and retain the first 100 unique destinations in document order. Count additional unique destinations as omitted and untested.

Choosing the first qualifying base is this checker's policy. It can differ from browser navigation when an earlier base declaration is invalid or unsuitable. A base on another origin can also change which destinations qualify for the same-origin selection shortcut.

Query strings remain part of the resolved URL, so different queries can produce separate findings. Empty and fragment-only addresses can resolve to the base document and are not automatically skipped. Removing a fragment groups document requests; it never validates the referenced section.

Original href contains the parsed attribute value, with HTML character references decoded, rather than a byte-for-byte copy of source markup. Anchor text is limited to its first 200 UTF-16 code units before whitespace is condensed. Duplicate links retain the first occurrence's text rather than a list of every label.

Complete source HTML and request boundaries

Source retrieval uses GET and requires a successful final response with the text/html content type. HTTP 206 and any response carrying a Content-Range header are rejected so a partial document cannot become a page inventory. A different media type, an oversized body, or invalid text decoding also prevents a new inventory.

The HTTP charset declaration determines text decoding. UTF-8 is used when that declaration is absent, and HTML <meta charset> declarations are not used to guess an encoding. Unsupported encodings and invalid encoded text are rejected. The source-page rejection of 206 is separate from outgoing status classification, where a complete 206 observation falls within the reachable 2xx range.

Outgoing checks start with HEAD, which asks for response metadata without a response body. A 405 response permits a separate GET attempt; other failures do not trigger that fallback. A 303 redirect also switches the next request to GET. Completed-chain evidence records the methods used and marks a 405 fallback. HTTPS certificate validation remains enabled for both source retrieval and outgoing checks.

Each request step along a redirect chain is a hop. The bounds below limit the amount of source material and network work in each operation. Selecting the maximum batch does not guarantee that every destination will finish.

Boundary Limit and consequence
Complete source HTML 512 KiB, or 524,288 bytes, after transfer decompression and before character decoding. Larger HTML is rejected rather than partially parsed.
Source transfer 2 MiB per compressed or decoded stage and 8 MiB of cumulative reads, within an 8-second service time limit.
URL length 8,192 UTF-16 code units before parsing and after serialized resolution and fragment removal. Submitted address strings must also fit 8,192 UTF-8 bytes. Overlong addresses are rejected or skipped.
Extraction and retention Up to 50,000 anchors with an href and 50,000 base declarations with an href are accepted. Exceeding either bound prevents a valid inventory. Within an accepted inventory, only the first 100 unique eligible URLs are retained for checking.
Selected request 1 to 20 retained URLs, with a 64 KiB limit on the submitted request. Long URLs can require a smaller batch.
Redirect following At most 5 redirects for source retrieval and at most 5 for each outgoing check. An unfinished outgoing chain remains inconclusive.
Outgoing request time Up to 2,500 ms per request attempt, including a separate GET attempt after 405. All selected URLs and fallback attempts share at most 8 seconds; available time can be shorter.
Returned response A 12-second browser wait per submitted request includes reading and parsing the response. The response size limit is 4 MiB.

Elapsed (ms) records the checking request, rather than browser rendering or complete page-load time. Results can change with request method, checking location, DNS resolution, certificate validity, destination access rules, and server load. Comparisons are most useful when the source and selected destinations stay consistent.

Rechecks, cancellation, and earlier observations

Returned evidence is matched to the requested URL. A completed recheck replaces earlier observations for the selected destinations while keeping observations for other destinations. The summary and findings can therefore combine observations from several batches, rather than one simultaneous assessment.

If a selected URL is absent from an otherwise valid response, it receives an inconclusive missing-result observation. A failed batch also marks its selected destinations inconclusive, replacing any earlier observations for them. Findings for destinations outside that batch remain available.

Cancel request preserves inputs and earlier findings, and a late response cannot replace them. Cancellation does not recall requests already received by another service. Editing the page URL clears the old inventory and observations. A successful source fetch starts a fresh inventory; a failed refetch can leave earlier findings visible without turning them into evidence of a new successful fetch.

Privacy Notes:

The source URL is sent to the checking service when you select Fetch page. A status check sends the selected destination URLs, and the corresponding websites can receive requests. Your signed-in browser session is not forwarded, so private or authenticated pages are outside the supported workflow.

  • Keep signed URLs, access tokens, and sensitive query values out of the source field and selected destinations. Query values are preserved in link addresses.
  • Source URLs, selections, and findings are not saved in browser storage or the tool's shareable URL. Only the same-origin selection preference can be restored through that URL.
  • Source HTML is discarded after extraction and excluded from reports. Reports still contain URLs, anchor text, source attribution, and request evidence, so review them before sharing. Public availability alone does not grant permission to republish page content.

Worked Examples:

Relative links after a page move

Suppose a page at /start on example.com is retrieved over HTTPS and redirects to /docs/page, with no usable base override.

Anchors containing missing#one and missing#two first resolve into the redirected page's /docs/ directory. After fragment removal, both point to /docs/missing on that same origin, producing one finding with 2 occurrences. If a selected check then records a complete final 404 response, that destination becomes Broken. Both source occurrences deserve review even though only one destination was checked.

One broken link in a partly checked page

In a hypothetical inventory of 12 unique links, a five-link batch returns complete final responses of 200, 404, 403, and 429, plus one timeout. The findings contain one Reachable, one Broken, one Restricted, one Throttled, and one Inconclusive destination, with 7 still Untested. Observed is 5 because the timeout is also an observation. Review the missing destination, prepare the seven untested links for another batch, and select the timed-out destination separately if it needs a recheck. The single broken-link count does not describe the seven untested destinations.

References: