HTML Guides for carriage return

The HTML specification explicitly forbids numeric character references from expanding to certain control characters, and the carriage return (U+000D) is one of them. Even though you can type 
 or in your markup, the spec defines this as a parse error. Browsers may handle it inconsistently — some will silently discard it, others may convert it to a different character — so relying on it leads to unpredictable behavior across environments.

The reason carriage return is singled out is rooted in how HTML normalizes line endings. During parsing, all carriage return characters (and carriage return + line feed pairs) are normalized to a single line feed (U+000A). Because the character is never preserved as-is, referencing it serves no practical purpose and is treated as an error. The WHATWG HTML Living Standard lists U+000D among the characters that must not appear as numeric character references.

Control characters in general are problematic in HTML text content. Most of them (U+0001 through U+001F, excluding tab, line feed, and form feed) are disallowed. The carriage return falls into this category because, after normalization, it effectively doesn’t exist in the parsed document.

How to fix it

1. Remove it — In most cases, the 
 reference is unnecessary. Simply delete it.
2. Replace with 
 — If you need a line break character reference (for example, in a title attribute or a pre element), use 
 (LINE FEED), which is a permitted space character in HTML.
3. Use <br> — If you need a visible line break in rendered content, use the <br> element instead of a character reference.

Examples

Incorrect: using a carriage return character reference

<p>First line&#13;Second line</p>

This triggers the validation error because &#13; expands to the carriage return control character.

The same error occurs with hexadecimal notation:

<p>First line&#x0D;Second line</p>

Correct: using a line feed character reference

<p>First line&#10;Second line</p>

The &#10; reference expands to LINE FEED (U+000A), which is allowed in HTML. Note that in normal flow, this renders as collapsible whitespace — it won’t produce a visible line break unless you’re inside a pre element or using CSS white-space: pre.

Correct: using <br> for a visible line break

<p>First line<br>Second line</p>

If the goal is a visible line break in the rendered output, the <br> element is the standard and most reliable approach.

Correct: line break in an attribute value

Sometimes &#13; appears in attribute values where a newline is intended, such as in title tooltips:

<!-- Incorrect -->

<span title="Line one&#13;Line two">Hover me</span>

<!-- Correct -->

<span title="Line one&#10;Line two">Hover me</span>

The &#10; reference is valid and some browsers will render it as a line break within tooltip text, though this behavior is not guaranteed across all browsers.

The HTML specification requires that URL attributes like src contain valid URLs. While browsers are generally forgiving and may strip or ignore whitespace characters in URLs, including tabs (\t), newlines (\n), or carriage returns (\r) inside a src value is technically invalid. These characters are not legal within a URL according to both the HTML and URL standards.

Beyond standards compliance, there are practical reasons to fix this:

• Unpredictable behavior: Different browsers may handle embedded whitespace differently. Some might silently strip it, while others could encode it as %0A or %0D, leading to broken image requests.
• Debugging difficulty: Invisible characters make URLs fail silently. The path looks correct in your editor, but the actual HTTP request goes to a different (malformed) URL.
• Accessibility and tooling: Screen readers, crawlers, and other tools that parse your HTML may not handle malformed URLs gracefully, potentially causing images to be skipped or reported as broken.

Common Causes

This issue typically appears in a few scenarios:

1. Multi-line attributes in templates: When a URL is built dynamically in a template engine (e.g., PHP, Jinja, Handlebars), line breaks in the template code can leak into the rendered attribute value.
2. Copy-paste errors: Copying a URL from a document, email, or another source may include hidden line breaks or tab characters.
3. Code formatting: Some developers or auto-formatters may break long attribute values across multiple lines, inadvertently injecting newlines into the value.
4. String concatenation: Building URLs through string concatenation in server-side code can introduce whitespace if variables contain trailing newlines.

Examples

Incorrect: Newline inside src value

The newline before the closing quote makes this an invalid URL:

<img src="images/photo.jpg
" alt="A scenic photo">

Incorrect: Tab character in src value

A tab character embedded in the middle of the URL path:

<img src="images/   photo.jpg" alt="A scenic photo">

Incorrect: Multi-line URL from template output

This can happen when a template engine outputs a URL with leading or trailing whitespace:

<img src="
  https://example.com/images/photo.jpg
" alt="A scenic photo">

Correct: Clean, single-line src value

The URL is a single continuous string with no tabs, newlines, or carriage returns:

<img src="images/photo.jpg" alt="A scenic photo">

Correct: Long URL kept on one line

Even if the URL is long, it must remain on a single line without breaks:

<img src="https://cdn.example.com/assets/images/2024/photos/scenic-landscape-full-resolution.jpg" alt="A scenic photo">

How to Fix It

1. Inspect the attribute value: Open the raw HTML source (not the rendered page) and look at the src value character by character. Use your editor’s “show whitespace” or “show invisible characters” feature to reveal hidden tabs and line breaks.
2. Remove all whitespace inside the URL: Ensure the entire URL is on a single line with no tabs, newlines, or carriage returns anywhere between the opening and closing quotes.
3. Check your templates: If the URL is generated dynamically, trim the output. Most languages offer a trim() or strip() function that removes leading and trailing whitespace including newlines.
4. Lint your HTML: Use the W3C validator or an HTML linter in your build pipeline to catch these issues automatically before deployment.