A newline (frequently called line ending, end of line (EOL), next line (NEL) or line break) is a control character or sequence of control characters in character encoding specifications such as ASCII, EBCDIC, Unicode, etc. A newline is used to signify the end of a line of text and the start of a new one.
History
In the mid-1800s, long before the advent of teleprinters and teletype machines, Morse code operators or telegraphists invented and used Morse code prosigns to encode white space text formatting in formal written text messages. In particular, the Morse prosign (mnemonic break text), represented by the concatenation of literal textual Morse codes "B" and "T" characters, sent without the normal inter-character spacing, is used in Morse code to encode and indicate a new line or new section in a formal text message.
Later, in the age of modern teleprinters, standardized character set control codes were developed to aid in white space text formatting. ASCII was developed simultaneously by the International Organization for Standardization (ISO) and the American Standards Association (ASA), the latter being the predecessor organization to American National Standards Institute (ANSI). During the period of 1963 to 1968, the ISO draft standards supported the use of either carriage return plus line feed (+) or alone as a newline, while the ASA drafts supported only +.
The sequence + was commonly used on many early computer systems that had adopted Teletype machines—typically a Teletype Model 33 ASR—as a console device, because this sequence was required to position those printers at the start of a new line. The separation of newline into two functions concealed the fact that the print head could not return from the far right to the beginning of the next line in time to print the next character. Any character printed after a would often print as a smudge in the middle of the page while the print head was still moving the carriage back to the first position. "The solution was to make the newline two characters: to move the carriage to column one, and to move the paper up." In fact, it was often necessary to send extra padding characters—extraneous s or s—which are ignored but give the print head time to move to the left margin. Many early video displays also required multiple character times to scroll the display.
On such systems, applications had to talk directly to the Teletype machine and follow its conventions since the concept of device drivers hiding such hardware details from the application was not yet well developed. Therefore, text was routinely composed to satisfy the needs of Teletype machines. Most minicomputer systems from DEC used this convention. CP/M also used it in order to print on the same terminals that minicomputers used. From there MS-DOS (1981) adopted CP/M's + in order to be compatible, and this convention was inherited by Microsoft's later Windows operating system.
The Multics operating system began development in 1964 and used alone as its newline. Multics used a device driver to translate this character to whatever sequence a printer needed (including extra padding characters), and the single byte was more convenient for programming. What seems like a more obvious choice – – was not used, as provided the useful function of overprinting one line with another to create boldface, underscore and strikethrough effects. Perhaps more importantly, the use of alone as a line terminator had already been incorporated into drafts of the eventual ISO/IEC 646 standard. Unix followed the Multics practice, and later Unix-like systems followed Unix. This created conflicts between Windows and Unix-like operating systems, whereby files composed on one operating system could not be properly formatted or interpreted by another operating system (for example a UNIX shell script written in a Windows text editor like Notepad).
Representation
Earlier history in Telegraphy and typewriters generally considered starting a new line a single action, and it would make sense to encode it as a single control character. However, the design of printing teletypes led to the idea of a newline being two actions, a carriage return and line feed . A by itself was useful to overprint the current line to make double-struck bold or underscores. A going straight down was mechanically simpler and could print some text faster if there was a working backspace. Requiring two characters to start a line did not waste any time as the mechanisms were slower than the time it took to send both of them (often extra "padding" characters had to be sent to be sure the carriage had reached the left before the next printing character). The was always sent first as it was the slow one.
If software did not want to process the characters before sending them to a teletype, this meant that each newline had to be stored as the pair or , on paper tape or in text files. Often the "padding" characters had to be stored as well.
Making newline be a single character just like space is helpful for text processing and pattern matching, and made the files smaller. Some systems did require to go to the left edge and many terminals had a configuration option to allow this (though this broke too much software that relied on going straight down). Multics and thus Unix instead required processing, a sent to a terminal was replaced by the operating system with (or whatever the terminal needed including padding characters).
+Operating system representation of a newline using ASCII control characters Operating system Abbreviation hex value dec value Escape sequence Multics, POSIX standard oriented systems: Unix and Unix-like systems (Linux, macOS, *BSD, AIX, Solaris, Xenix, etc.), QNX 4+Others: BeOS, Amiga, RISC OS, Sinclair QDOS Windows, MS-DOS compatibles, Atari TOS, DEC TOPS-10, RT-11, CP/M, MP/M, OS/2, Symbian OS, Palm OS, Amstrad CPC, and most other early non-Unix and non-IBM operating systems Commodore 64, Commodore 128, Acorn BBC, ZX Spectrum, TRS-80, Apple II, Oberon, classic Mac OS, HP Series 80, MIT Lisp Machine, and OS-9 Acorn BBC and RISC OS spooled text output QNX pre-POSIX implementation (version < 4)
EBCDIC systems—mainly IBM mainframe systems, including z/OS (OS/390) and IBM i (OS/400)—use (New Line, )IBM System/360 Reference Data Card, Publication GX20-1703, IBM Data Processing Division, White Plains, NY as the character combining the functions of line feed and carriage return. The equivalent Unicode character () is called (Next Line). EBCDIC also has control characters called and , but the numerical value of () differs from the one used by ASCII (). Additionally, some EBCDIC variants also use but assign a different numeric code to the character. However, those operating systems use a record-based file system, which stores text files as one record per line. In most file formats, no line terminators are actually stored. Operating systems for the CDC 6000 series defined a newline as two or more zero-valued six-bit characters at the end of a 60-bit word. Some configurations also defined a zero-valued character as a colon character, with the result that multiple colons could be interpreted as a newline depending on position. RSX-11 and OpenVMS also use a record-based file system, which stores text files as one record per line. In most file formats, no line terminators are actually stored, but the Record Management Services facility can transparently add a terminator to each line when it is retrieved by an application. The records themselves can contain the same line terminator characters, which can either be considered a feature or a nuisance depending on the application. RMS not only stores records, but also stores metadata about the record separators in different bits for the file to complicate matters even more (since files can have fixed length records, records that are prefixed by a count or records that are terminated by a specific character). The bits are not generic, so while they can specify that or or even is the line terminator, they can not substitute some other code. Fixed line length was used by some early mainframe operating systems. In such a system, an implicit end-of-line was assumed every 72 or 80 characters, for example. No newline character was stored. If a file was imported from the outside world, lines shorter than the line length had to be padded with spaces, while lines longer than the line length had to be truncated. This mimicked the use of punched cards, on which each line was stored on a separate card, usually with 80 columns on each card, often with sequence numbers in columns 73–80. Many of these systems added a carriage control character to the start of the next record; this could indicate whether the next record was a continuation of the line started by the previous record, or a new line, or should overprint the previous line (similar to a ). Often this was a normal printing character such as that thus could not be used as the first character in a line. Some early line printers interpreted these characters directly in the records sent to them.
Communication protocols Many communications protocols have some sort of new line convention. In particular, protocols published by the Internet Engineering Task Force (IETF) typically use the ASCII CRLF sequence.
In some older protocols, the new line may be followed by a checksum or parity character.
Unicode
The Unicode standard defines a number of characters that conforming applications should recognize as line terminators:
: Line Feed, : Vertical Tab, : Form Feed, : Carriage Return, +: () followed by () : Next Line, : Line Separator, : Paragraph Separator,
While it may seem overly complicated compared to an approach such as converting all line terminators to a single character (e.g. ), because Unicode is designed to preserve all information when converting a text file from any existing encoding to Unicode and back (round-trip integrity), Unicode needs to make the same distinctions between line breaks made by other encodings. For instance EBCDIC has , , and characters, so all three have to also exist in Unicode.
Most newline characters and sequences are in ASCII's C0 controls (i.e. have Unicode code points up to ). The three newline characters outside of this range—, and —are often not recognized as newlines by software. For example: JSON recognizes and as whitespace, but not any other newline characters. C0 controls cannot appear unescaped within strings, but any other line break characters can. ECMAScript only recognizes , , and as line terminators. Historically, unescaped line terminators were not permitted in string literals, but this was changed in to allow unescaped and in strings for compatibility with JSON. YAML 1.1 recognized all three as line breaks; YAML 1.2 no longer recognizes them as line breaks in order to be compatible with JSON. Windows Notepad, the default text editor of Microsoft Windows, does not treat any of , , or as line breaks. gedit, the default text editor of the GNOME desktop environment, treats and as line breaks, but not .
Unicode includes some glyphs intended for presenting a user-visible character to the reader of the document, and are thus not recognized themselves as a newline:
HTML In HTML, line breaks are whitespace and are generally treated no different to spaces. Paragraphs are created using separate instances of the HTML element , with the physical separation of paragraphs controlled by the rendering engine.
Line breaks can be explicitly created using the HTML element . To facilitate screen readers being able to interpret pages, HTML documentation recommends against using this element for paragraphing. Instead, sources including MDN Web Docs suggest using this element for poems.
In programming languages