Broken Link Syntax Checker
Paste text or HTML and catch malformed URLs before they go live.
About the Broken Link Syntax Checker
Broken links often come down to typos rather than dead servers, a missing http(s)://, a stray space, doubled slashes, or a malformed top-level domain. This checker scans pasted text for anything that resembles a URL and flags those patterns using regex rules alone, no network request is ever made, so a link can pass here and still 404 in the real world, or fail here despite working fine.
This is a syntax check, not a live link checker
Worth being precise about what "flagged" and "Looks OK" actually mean here, this tool never fetches a single URL, it evaluates whether each one is shaped like a well-formed link, not whether the page it points to actually exists. A syntactically perfect URL to a page that's been deleted still shows "Looks OK," and a working URL with an unusual but valid pattern can still get flagged. Catching a genuinely dead link requires a real request, which is intentionally outside what this tool does, checking syntax has the advantage of working on links that can't be fetched at all in a browser anyway, staging environments behind a login, internal intranet URLs, or links in a document that isn't published yet.
Why no request is ever made, by design
Not sending a request isn't just a technical limitation, it's deliberate. Fetching every URL found in pasted text would mean this tool acting as an uninvited crawler hitting whatever server each link happens to point at, including ones the person pasting the text has no relationship to or awareness of. Working purely from the text pattern keeps the check instant, keeps it private, nothing typed or pasted leaves the browser, and avoids generating unexpected traffic against someone else's server.
What "duplicate consecutive dots" usually catches
Two dots in a row, example..com or a domain ending in .com.com, is a specific, recognizable bug pattern rather than a stylistic issue, it almost always comes from a template or string-concatenation error, a base URL and a path getting joined with an extra separator character neither side expected. It's rare for a human typing a URL by hand to produce this pattern, which makes it a reliable signal that a link came from a broken generation process somewhere upstream rather than a simple typo.
Where flagged links actually come from
In practice, most links this tool catches didn't originate as a manually typed mistake, they come from copy-pasting out of a word processor that silently converts characters, a CMS field that got truncated mid-URL, or a mail-merge template where a variable didn't get filled in as expected. Pasting a whole block of content in here right before publishing catches that entire category of error at once, faster than checking each link individually by clicking through them one at a time.
Why the TLD check is intentionally loose
The check for a malformed top-level domain only flags a TLD shorter than two characters or one made entirely of digits, deliberately permissive rather than checking against a fixed list of known TLDs. New top-level domains get approved regularly, .app, .dev, .io, and dozens of others exist alongside the familiar .com and .org, hardcoding a specific list would mean this tool incorrectly flagging perfectly valid, if less common, domains as broken. The trade-off is that a URL with a plausible-looking but entirely made-up TLD, three or more letters that happen to look real, won't get caught by length alone, that's a case a live check would need to catch instead.
Frequently Asked Questions
Does "Looks OK" mean the link actually works?
No. This tool only checks whether a URL is syntactically well-formed, it never makes a network request. A syntactically valid URL pointing to a deleted or nonexistent page still shows "Looks OK," since verifying that requires an actual fetch, which this tool intentionally doesn't do.
Why doesn't this tool actually fetch the URLs to check if they're broken?
Fetching every pasted URL would mean this tool acting as an uninvited crawler against whatever server each link points to, including ones unrelated to the person using it. Checking syntax only keeps everything private, instant, and avoids generating unexpected traffic against someone else's server.
What does "Duplicate consecutive dots" usually mean?
It's a specific pattern, like example..com, that almost always comes from a template or string-concatenation bug rather than a manual typing mistake. It's a reliable signal the link was generated incorrectly somewhere upstream, worth tracing back to its source rather than just fixing the one instance.
Where do most flagged links actually come from?
More often from copy-pasting out of a word processor that silently converts characters, a truncated CMS field, or an unfilled mail-merge variable, than from someone manually mistyping a URL. Pasting a full block of content before publishing catches that whole category of error at once.
Why doesn't this tool check TLDs against a list of valid ones?
New top-level domains get approved regularly, .app, .dev, and .io are valid alongside .com and .org, so a hardcoded list would risk flagging legitimate but less common domains as broken. This tool only checks that a TLD is at least two letters and isn't purely numeric, which is deliberately permissive rather than exhaustive.