You can insert newline characters in many URLs and browsers will still navigate correctly. At first glance, this looks invalid, but modern browser URL parsers are more permissive than most developers expect.
This post continues a small series about HTML parsing surprises, like There is no self-closing tag in html.
#Newlines in URLs can still work
For example, this link works in browsers:
HTML
<a href="https://example.com/docs/
url-parsing">Documentation</a> <!-- must be tabs or newlines, not spaces -->
Browsers report a validation error internally when they encounter ASCII tabs or newlines in a URL, then strip those characters and continue parsing. Compliant parsers therefore navigate to the same destination as the equivalent URL without those characters. The WHATWG URL Standard describes this in the basic URL parser algorithm:
If input contains any ASCII tab or newline, invalid-URL-unit validation error. Remove all ASCII tab or newline from input.
WHATWG URL Standard
So these are generally interpreted the same way:
HTML
<a href="https://exa
mple.com/path">A</a>
<a href="https://example.com/path">B</a>
#Multi-line data URL with inline SVG
Data URLs can also be written on multiple lines. This is useful when embedding a readable inline SVG document:
HTML
<img alt="Simple sunset" src='data:image/svg+xml,
<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 120 80">
<rect width="120" height="80" fill="deepskyblue" />
<circle cx="60" cy="45" r="14" fill="gold" />
<rect y="58" width="120" height="22" fill="sienna" />
</svg>' />
This example is intentionally formatted for readability. For production code, many tools still prefer a single-line or percent-encoded representation.
#It can obfuscate mailto: from non-compliant regex parsers
This behavior can be used to obfuscate URLs such as mailto: from non-compliant parsers that rely on simple regex extraction.
HTML
<a href="mail
to:security@example.com">Contact security</a>
A browser resolves this as mailto:security@example.com, but a naive pattern like mailto:[^\"'\s>]+ may fail to detect it because of the embedded newline.
This matters for scraping, static analysis, anti-spam bots, and security scanners. Any tool that must detect links reliably should parse HTML and URLs with a standards-compliant parser rather than relying on regex alone.
#Limits and caveats
- Not all whitespace is accepted everywhere.
- The behavior depends on the parsing context and URL scheme.
- Some tools and validators may warn or reject such markup.
- Obfuscation is not a security control. It only targets weak parsers.
As a rule, write normal one-line URLs unless you have a strong reason to format them differently.
#Additional resources
Do you have a question or a suggestion about this post? Contact me!