Better Password Inputs, iPhone Style

Avatar of Chris Coyier
Chris Coyier on

Recently renowned usability expert Jakob Nielsen wrote an article Stop Password Masking in which he claims that hiding users passwords as they input them is bad practice. What he is referring to is the default browser behavior of <input type=password … /> elements, where text entered into them turns into bullets rather than showing the real characters typed. He says it reduces user confidence in what they type and thus beginning a string of problems like more typing errors, users choosing overly-simple passwords or copying and pasting complex ones (less secure). The effect is ultimately less user satisfaction and ponentially less profit for you.

Of course he is right about all that, but masking passwords isn’t something that was developed and made default just for shits and giggles. It is to keep prying eyes away from looking at your screen and learning your passwords. This fact isn’t lost on Jakob who suggests making it a checkbox-style option.

Admittedly, someone peeking at your screen to capture a password is pretty rare. I’m alone in my office right now, like I am most of the time, and I bet that plant in the corner doesn’t have any secret cameras in it. I’m sure a lot of you are in similar environments. But I’m of the opinion that leaving important security up to users is typically not a good choice. Gruber linked to Jakob’s article, noting that the iPhone has an interesting solution to this already in use.

How the iPhone handles password inputs

  • The iPhone inputs turns text into bullet points like web password inputs, but after a quick delay, allowing you to see the typed character for a brief time.
  • The iPhone keyboard has a popup as you press each character verifying visually what character you just typed.

This is a pretty damn nice way to handle password inputs, which can be translated into use on the web. This handling of password inputs is a combination between giving better user feedback on key presses, increasing user confidence, yet still mostly hiding the password making it more difficult for casual onlookers.

We can replicate the idea behind both of these things, using jQuery!

Displaying pressed keys

Here is some super simple form markup with a password input:

<form action="#" id="login-form-1">
      <label for="user-password">Password</label>
      <input type="password" id="user-password" name="user-password" />

We’ll use that internal div to set some relative positioning, and then set up some styling for a special div that we will insert on-the-fly in there for displaying the pressed key.

#login-form-1 div { 
   position: relative;
#login-form-1 div #letterViewer { 
   display: none; 
   position: absolute; 
   left: 240px; 
   top: -30px; 
   width: 100px; 
   font: bold 72px Helvetica, Sans-Serif; 

Then with jQuery, we can append that div and attach a keypress event to the input. When a key is pressed, that div will fade in with the letter, and fade back out. This will simulate the iPhones keyboard pressing letter verification.

$(function() {
    $("#login-form-1 div").append("<div id='letterViewer'>");
    $("#user-password").keypress(function(e) {
            .fadeIn(200, function() {

Of course, you could style this up any way you want.

Changing text to bullets / only displaying last character

The next theory is making the text into bullets as you type them, but only after a short delay allowing you to see the typed character briefly. This is a bit more difficult. You could change the password input to be of type=”text”, but then changing the value to bullets would be problematic because of course you need to submit the real value of the field not bullets. You can’t leave the input as type=”password”, because nothing can be shown in those inputs except bullets.

The solution is to duplicate the password field, change it to a text input, and hide the original. This way you can use the new field and manipulate it however you want, but ultimately you submit the now-hidden password input which you keep up to date with current typed data.

We could set into writing this, but fortunately the DECAFo blog has already done the heavy lifting and created a jQuery plugin to do just this.

Simply target your password input and invoke the plugin:


Of course like any good plugin, there is a bunch of options you can pass as parameters like the delay before switching, the prefix for the duplicated input, and more.


View Demo   Download Files


What do you guys think? Is this a good middle ground or the worst of both worlds?