Replace CRLF, CR and LF newline sequences with literal HTML br tags. Existing markup and special characters remain unchanged; no paragraphs or escaping are added.
The line break to BR converter replaces newline sequences in supplied text with literal “<br>” markup. Paste the input and select Convert to place the result in the separate output box. It is useful for an intentional sequence of lines, such as an address or a short formatted passage, when your destination expects HTML break elements. It does not decide whether every line in a document should semantically become a hard break rather than a paragraph or list.
Begin by identifying the source format and destination. A plain-text field may need real newline characters, while an HTML fragment can interpret break elements when rendered appropriately. Pasting literal markup into a field that expects text can simply display the tag spelling. Conversely, treating an unreviewed string as HTML can give existing source markup a role you did not intend. Choose the representation before converting rather than assuming one output works in every editor or publishing field.
The pattern recognizes Windows-style carriage-return plus line-feed pairs, lone carriage returns and lone line feeds. The pair is handled first, so one CRLF sequence becomes one br element rather than two. Mixed input can therefore be converted consistently at each actual newline boundary. The function does not infer a newline from visual wrapping in a narrow text box; the separator must exist as characters in the source string for the pattern to replace it.
For three words on separate lines, the result is “First<br>Second<br>Third”. There is no automatically appended break after the final word unless the source itself ends with a newline. A text editor's display width can make a single source line occupy many visible rows without changing this result. Use a small sample with a known number of hard breaks when a converted tag count seems different from the number of rows you saw while typing.
Two consecutive newlines produce two consecutive br elements, preserving the number of recognized break sequences rather than collapsing a blank row. A leading newline becomes an initial br, and a trailing newline becomes a final br. The converter does not trim the input or the output. These details are useful when the intended layout includes a deliberate blank line, but they can also expose accidental spacing copied at the beginning or end of a passage.
Review whether repeated breaks are actually appropriate for your HTML. A blank line between independent prose paragraphs may be better represented by paragraph elements in your normal document structure. This tool does not choose or wrap those elements for you. It performs exact newline replacement, so a successful conversion says nothing about whether a long document's hierarchy, spacing or semantics are well expressed by a sequence of hard line-break elements.
A real newline character is different from typing the two visible characters backslash and n. This function replaces the real separator, not every “\n” string embedded in the input. If copied material comes from a JSON string or a code example, it may need appropriate decoding through the source format before its intended lines exist as actual characters. Do not delete backslashes indiscriminately; they may be literal content that should remain visible in the final example.
Likewise, the text “<br>” already present in input is not a newline sequence to this replacement. It remains unchanged, while actual newlines elsewhere receive new tags. The operation does not detect duplicate intentions such as an existing br immediately followed by a newline, so both can remain represented in the output. Inspect that combination when converting an HTML fragment that already has some breaks instead of assuming the tool will merge equivalent representations automatically.
The converter does not replace ampersands, angle brackets or quotes with entities. Existing “<b>” syntax remains markup-like text in the generated string, and adding br tags does not make the whole result sanitized. If the source is intended as literal user text, decide how it should be encoded in the final HTML context. Use the application's appropriate safe rendering workflow rather than assuming a newline helper has validated or neutralized every other character in the passage.
Encoding order matters when you prepare a literal-text fragment with deliberate break elements. Escaping an entire finished HTML string can encode the newly inserted br tags so they display as text rather than creating breaks. Leaving the original text unescaped can have a different effect. Define which parts are text and which are trusted structural markup through your application's rendering model; this small tool cannot make that context-specific distinction or choose the integration policy for you.
Letters, digits, internal spaces and punctuation are unchanged by the replacement itself. The converter does not translate scripts, normalize Unicode or correct spelling. Hindi or accented text can pass through with the same content characters while the recognized newlines become tags. If words appear joined or spacing changes after publishing, inspect how the destination parses and styles the output instead of assuming the converter performed a general text cleanup or language transformation.
For code snippets or data exports, replacing line endings with HTML markup can make the source unusable in its original format. Work from a copy and use this result only in a destination that actually needs the HTML representation. Keep the original newline-bearing version for further processing when required. A string that renders acceptably as a web snippet is not necessarily a valid CSV record, program or plain-text document after tags have been inserted at every boundary.
A line break expresses a hard break inside its surrounding context; a paragraph or list conveys a different structure. Use the converter for the representation your task requires rather than treating every copied visual row as a new semantic unit. PDF text can contain hard wraps that merely reflect column width, and converting each into br can preserve an awkward layout instead of recovering the intended prose paragraphs. Review those source boundaries first.
If your goal is to remove accidental wraps, use a line-joining workflow and understand its own preservation limits. If your goal is paragraph markup, use a suitable converter or document model that maps the intended paragraph boundaries. This utility is deliberately narrower. Explaining that scope helps a reviewer assess the output based on the chosen task instead of calling a sequence of generated br elements a complete or automatically well-structured HTML document.
Select Convert again after editing the input because the separate output reflects the most recent action. Copy the checked string manually, then inspect the destination's source and rendered result where relevant. Count the actual newline boundaries in a small sample if you need to verify CRLF or blank-line handling. A preview that shows literal tags in a textarea is expected: that box displays the generated string rather than rendering it as active layout.
Save both the original and the chosen representation in your normal workflow when exact line structure matters. The converter does not create a page, apply CSS or certify safe insertion into every context. Its useful outcome is an understood mapping from specific newline characters to literal break elements. Correct content, appropriate structural choices and the final rendering remain part of the surrounding publishing or application task rather than properties guaranteed by pressing the conversion button.
It replaces CRLF pairs, lone CR and lone LF sequences with literal br elements.
No. The CRLF pair is matched as one sequence before the single-character alternatives.
No. Consecutive newline sequences produce consecutive br elements.
Only when the input has a trailing newline. There is no separate automatic final break.
No. The function targets real newline characters, not the two visible characters used in an escape notation.
No. Existing markup remains, so a tag followed by a real newline can lead to another inserted break.
No. Other content is left unchanged, and this operation is not sanitization.
No. It only replaces recognized newline sequences.
No. A visible row wrap is not necessarily an actual newline character.
Select Convert again after an edit to generate a current result.