Jakob Nielsen suggested it in 2009 (http://www.nngroup.com/articles/stop-password-masking/), and Luke W concurs (http://www.lukew.com/ff/entry.asp?1653), but are there any real-world implementations of such "visible password" fields?

Do you have examples or real-word experience of websites that show the password in plain text by default on registration or sign-in forms?

What are the issues? (apart from the obvious of someone looking over your shoulder with a note pad)

  • 2
    I assume you mean on desktop, because it's reasonably common on mobile devices to have plain text passwords. Certainly it's very common to have the last letter stay plain text for a couple of seconds before turning into a bullet or other 'hidden' character, and the user also has the control sometimes on mobile to show, all, part or none of the password in plain text. Oct 11, 2013 at 16:50
  • 1
    login.mailchimp.com has a checkbox to turn the password from blacked-out to plain text.
    – kontur
    Oct 11, 2013 at 17:59
  • Sure Facebook do it on mobile if you make a mistake due to mobile keyboards being a bit awkward
    – Toni Leigh
    Oct 11, 2013 at 21:28
  • @RogerAttrill Yeah - I'm mainly interested in desktop I guess - mobile websites would be great too. Or household-name mobile apps, but apps are generally sign in once and stay signed in forever which is a different experience.
    – edeverett
    Oct 12, 2013 at 13:57
  • @kontur, @ ColinSharpe Thanks, I'm really looking for examples that have the password plain text as default.
    – edeverett
    Oct 12, 2013 at 13:57

3 Answers 3


With all the concern about the security implications of someone "looking over the user's shoulder" I think we forget the actual user experience of showing the plain password.

A password is usually something you don't want known and most often it has personal meaning to the user. The obfuscated way of showing passwords re-enforces a sense of security to the user, by visually showing them that, as it were, even the interface they are entering their password to is unable to just read the secret token the user has chosen. Technically, of course, this is a whole different matter, but user interfaces communicate more than just technical facts or program state.

Traditionally, users are prone to use very personal pass phrases (against IT experts' advice, of course), like a loved one, some place of meaning, an item of affection they feel strong about... What I am getting at is that there is a cryptographic interest for the user to not want a password visible in plain text, but there is also a psychological or social aspect, i.e. "I don't want my reference to this 'dearest thing' on display", as it might not be something the user would openly admit to or endorse.


Smashing Magazine also covered this in their article:


At the bottom is the example of facebook who give you a plain text password field if you fail to get the password right on mobile login.

The obvious one is people looking over your shoulder, but this would actually be quite tricky, the hacker would need to get the email address and the website unless they knew the person plus we often interact in places where we are alone or where our shoulders cant be looked over.

Another less obvious problem is that it could give your site an appearance of being insecure, even if used in a secure environment, as passwords are almost always obscured and users might not necessarily know the technicalities of how browsers process them. Could you imagine a non-technical user who trusted an online bank that let them enter their passwords in plain text ?

The main issue is a balance of security (implied and real) vs. ease of use, particularly for repetitive actions like login - you might like to read this article for some more detail on this.



The use case for sign-in and registration are different. When you're signing in you know your password (unless you've forgotten it), so the main reason for using plaintext is to prevent typing mistakes. However when you're registering you're entering new data rather than confirming existing data, so the potential impact of a typo is greater. This is why registration forms typically have a second 'Confirm password' field.

I engaged with this issue earlier this year when I re-designed a login/registration form for a client. My preferred design pattern was the mobile phone one Roger Attrill mentions where the last letter of the password is shown in plain text for a few seconds before being masked by a bullet. I did find some js plugins that replicate this behaviour for desktop, but they all had some shortcomings so I didn't go with this approach.

The solution I went with reflects the difference between sign-in and registration behaviour.


Standard masked password input. This reinforces a sense of security (as mentioned by kontur), but is prone to unnoticed typos. The overriding reason I stuck with this pattern though was it matches user expectations.

form

Registration form

Augmented password field with SHOW/HIDE button. No secondary 'Confirm password' input. This allows the user to show/hide their password, visually confirming what they've typed in. Being able to see your password means there's no need for a password confirmation field which keeps the registration form shorter and simpler.

Registration form

The jquery code for this is: (apologies to non-jquery purists)

// Show/hide plain text password
$('#pw a').on('click', function() {
  var $pw = $('#pw input.pw').not('.placeholder'), $txt = $('#pw input.txt');
  var isNowTxt = $('#pw').toggleClass('plain').hasClass('plain');
  isNowTxt ? $(this).text('Hide') : $(this).text('Show');
  isNowTxt ? $txt.val($pw.val()) : $pw.val($txt.val() != $txt.attr('placeholder') ? $txt.val() : '');
  isNowTxt ? $txt.focus() : $pw.prev().length ? $pw.prev().focus() : $pw.focus();

// and make sure the password value is correctly submitted
$('#pw a').closest('form').on('submit', function() {
  if ($('#pw .txt').is(':visible')) $("#pw a").click();
  • Hey @Mark_Chitty, good first post and reasoning. Usually implementation is out of scope on this particular stackexchange Q&A board, so you need not worry about actual code for solving a suggested problem :)
    – kontur
    Oct 16, 2013 at 6:31

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.