Chrome – are you sanitising my inputs without my permission?

I had to write this as I’m going mad, and I can’t really work out if it’s me, or if Chrome is indeed utterly fecking with my inputs.

I’m creating a form that takes (as a hidden variable) a string like this:


Double pipes at start and end are put there by me to denote where the carriage returns occur.  In particular, you can see there is a carriage return after the last character.

Browsers that work

When I render this out in a hidden field in firefox (or indeed any browser other than chrome), I get the following when viewing source:

<input name="PaReq" type="hidden" value="eJxdUt1ugjAUvvcpml1tN5QiKpraROeSmQxnNl+gKyfKJgVLGbqnX4tW0CYk/X5oT79z6GanABaf

" />

Notice in particular that the form field ends with the correct carriage returns.

When posting this to the third party provider (this is a 3D Secure transaction, letters have been changed to protect the wealthy!), jobs a good un, works no problem at all.

What happens in Chrome

When I view the same source in Google Chrome (5.0.375.99), I get the following:

<input name="PaReq" type="hidden" value="eJxdUl1vwiAUffdXkD1tLwVq/QyS1Pkwk9WZzT/A6I02U6qUrrpfP6hiW0mb3HPPAS7nXrbZaYDF

Erm… Chrome – where did you put those carriage returns?

I’ve tried deliberately placing carriage returns on the hidden field, adding them to the variable, etc. and still, it removes them.

It’s almost like the value has had a .Trim() applied before being output?

This transaction fails (oddly enough, invalid paReq), and although I can’t prove it, my guess is that the carriage returns are significant in this.


Am I going mad here?  Am I missing something obvious?  Is this a bug or indeed a feature?


This has now been confirmed by a few people – terrifying though that is. If whitespace is important to your form inputs (well, trailing whitespace), then the cry is ‘be careful!’.

Someone suggested a workaround on stackoverflow ( which works a treat, and out of all solutions I can think of, is the most elegant.

Thanks for the feedback from all – it’s been a really useful exercise!

  • Pingback: Tweets that mention Chrome – are you sanitising my inputs without my permission? --

  • View source can’t be relied upon, as FF and Chrome show you what the parsed DOM thinks it has – not necessarily the actual text that was sent. Of course this may be the crux of your problem: that these CRLFs are being “normalised” out of the form field. In any case use Fiddler to see what’s really going back and forth: espcecially in the POST to the 3rd party service.

  • Did a quick test, and it looks like yes Chrome is trimming trailing CRLFs! You can add them with JavaScript and it maintains them (e.g. “if PaReq field doesn’t end with ‘\r\n’ then append ‘\r\n'”)

  • admin

    unbelievable eh! Sack the juggler that let that one through the door from UAT!

  • Hi

    I blogged about this a while back here

    The textarea seems to be working a treat for us as we been in production with it for a few months.

  • I’ve got *exactly* the same problem with the DataCash post. Darn Chrome! Grrrr….