How to Add a New Line in PHP (Line Breaks, Explained)

Suppose you’re building an app using PHP. (Which, since you’re reading this, you probably are.)

You need to include a long string of text that needs to be broken by line breaks so it’s easy for your users to read. And so, you found yourself wondering…

What’s the best way to accomplish this?

To add new lines to a string in PHP, echo the string using the nl2br() function, adding \n wherever you want the lines inserted. The function will return a string with a <br /> element inserted before every \n character.

It is as simple as that. If you haven’t used the nl2br() function (the name stands for “newline to break”), it takes a while to learn the ropes. In the rest of this post, I’m going to show you exactly how to use it.

How the nl2br() Function Works

PHP, like most other programming languages, has support for the “end of line” or “newline” character, which tells the interpreter to insert a newline in the output of your code.

This is done by using the nl2br() function. The function parses the string, looks for \n characters, then returns a new string with \n converted into <br /> elements. In turn, the user’s browser converts the <br /> elements into line breaks as it renders the DOM.

Newline With /n

In the simplest implementation imaginable, your use of the nl2br() function would look like this:

<?php
echo nl2br("Insert a new line \nbefore here");
?>

The above function will return the following output:

Insert a new line <br />before here

It’s important to note the PHP also allows you to use \r, \r\n, and \n\r instead of \n for end of line characters. You can use these interchangeably, although—to make your code consistent and easy to debug—it’s a good idea to select one and stick to it.

Newline With \r

So, whether you use this:

<?php
echo nl2br("Insert a new line \rbefore here");
?>

Newline With \n\r

Or this:

<?php
echo nl2br("Insert a new line \n\rbefore here");
?>

Newline With \r\n

Or, last but not least, this:

<?php
echo nl2br("Insert a new line \r\nbefore here");
?>

With the nl2br() function, it won’t necessarily make a difference.

Which Line Break Character to Use?

Decisions, decisions… Which newline character should you use?

The \r is for “carriage return” and originates from the days when the paper carriage on typewriters and mechanical printers had to be slid back into position and rotated upward to start a new line. The \n stands for “newline” for a new line triggered by the “typist.”

Operating systems and programming languages in the early days of computing adopted both carriage return (\r), newline (\n), and the carriage return followed by newline (\r\n) as it was sequenced on typewriters.

Of course, each picked up a different one:

• The ASCII standard is \r\n, and this is what MS DOS used;
• UNIX used \n instead, and it got picked up by many languages;
• Before OS X, Macs used an \r. Post OS X, Macs used the UNIX \n.

Nowadays, which one to use comes down to your personal preference. Carriage return keeps the mouse cursor on the existing line, whereas newline moves it to the new line.

With all that said, most of the programmers I know use \n for the languages that support it. Also, in terms of length, \n and \r require half the characters as \r\n and \n\r, so I see no reason to use the latter.

The Alternative: PHP_EOL

In PHP, there’s a reserved word called PHP_EOL. It’s basically a predefined constant that the PHP documentation describes as “The correct ‘End of Line’ symbol for this platform.”

PHP_EOL, as you will see in the code snippet below, eliminates the need to use the nl2br() function:

<?php
$text = "Insert a new line" . PHP_EOL . "before here";
echo $text;
?>

According to a user in this Stackoverflow thread, the purpose of PHP_EOL is to automatically choose the correct line break character so that your code is always compatible, no matter the operating system it’s run on.

In Conclusion

That’s that. Though there are more ways to approach this, the nl2br() function and the PHP_EOL predefined constant should do the job, respectively, for HTML and non-HTML apps.

Let me know in the comments if you can think of any sleeker approaches, or if you’ve come across any limitations or edge cases of the above that are worth sharing with the rest of this post’s readers.