It's been my experience over the past few years that the majority of contact forms on web pages of both large companies as well as governmental institutions fail to handle line breaks properly in one way or another.

Typically, such a contact form consists of several single-line text boxes for contact details of the inquirer and one multi-line text box intended for the actual message:

contact form sketch

When using such a form, I give the message a classic business letter/e-mail look and feel. I include salutation, closing and multiple paragraphs separated by line breaks to make the message as easy to read as possible for the customer service person on the other end.

I find that line breaks in the actual message often get messed up:

  • Many times I would receive a confirmation e-mail repeating all the data I've entered. Usually, there would be one field per line and the line containing the "your message" field would present the message entirely without line breaks, making it really hard to read for anyone.
  • Even if I don't receive a confirmation e-mail (or the mail wouldn't include any information entered into the form) I often find out from the reply, that customer service received the message in a way described above, with all line breaks gone.

Name: John
E-mail: [email protected]
Message: Hello, my name is John and I would like to know more about UX. Please let me know if there is a way to achieve X using Y. Thanks in advance. Best wishes, John

Being involved in web development myself, I'm aware that handling line breaks can sometimes involve a little work in order to make them work correctly. On the other hand, failure to handle line breaks at all would seem like a beginner's mistake.

Thus my question(s): Why is removal of line breaks in contact form messages so common? Is there a specific reason from UX point of view to disregard line breaks in contact form fields?

  • 1
    I would take a guess that the actual newline character entered is stored and maybe even sent with the email but the email view itself is HTML which does not show these newlines as linebreaks. It could very well be a bug that the software is not replacing newline characters with HTML <br> tags so they persist in HTML emails.
    – rgthree
    Jul 21, 2016 at 5:08
  • I also think it's possible that some sites who are scared of cross-side-scripting simply remove all HTML elements. Or there's a certain step when converting the input string to whatever variable that breaks line breaks as you said. I'm actually also very interested in this topic. Jul 21, 2016 at 6:52

3 Answers 3


I would guess that any of the following could be the cause:

  • The Designer did not think of this
  • The Product Owner or BSA did not specify it
  • The Developer was too junior so didnt know how to do it
  • The widget used did not alow it
  • The tech stack they used prevented it
  • The security policy vetoed it
  • There wasn't enough time to do anything fancy (e.g, MVP)

The bottom line is if this was specified in the design and everyone in the team agreed to do it, then the developers would have found a way to meet the design without falling foul of the security policies, and the data entered by the user would be converted with line breaks.


In my experience, this all comes down to the developer of the contact form not replacing the line breaks with proper HTML equivalents in the email message (sent as HTML). Options to format this correctly are to wrap chunks of text with line breaks between them into paragraphs (p) or to simply insert break tags (br) wherever you see a line break.

If the email message were sent as plain text, things would mostly be OK. I say "mostly" because even then there are issues with what constitutes a line break. Is it a linefeed (LF, \n) only, a carriage return (CR, \r) only, or a combination of the 2 (CRLF, \r\n)?

What I do in my email message translations is stick to the RFC standard for plain text emails, which prefers CRLF. When sending HTML messages, I replace explicit CRLF pairs first with br tags, then look for CR and LF individually to also replace with br tags. That typically handles whatever combination is sent to the server on form submission.

It really makes sense to keep the line breaks when translating a message to an email. Likewise, some systems store the user's message and show it on a web page for later reference (history). The same thing typically happens on those pages when the line breaks are not properly transformed (if at all).


Having just configured a website with an F5 Web Application Firewall (WAF) it appears that carriage-return and line-feed characters are commonly blocked to frustrate SQL-injection and cross-site scripting attempts - hence why you see this in corporate websites a lot. I imagine that blocking the charazcters is less effort than encoding the text box or using some other technique to remove these characters but retain formatting.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.