Hide/Show Passwords: The Missing Plugin

Written by Tyler Sticka on

It’s easy to take the “masking” of passwords (replacing characters with ••••) for granted. As Luke Wroblewski documented last November, this practice increases login failures while providing little-to-no security benefit.

Here’s the alternative Luke and his team built into Polar:

By default Polar displays your password on our Log In screen as readable text. A simple, Hide action is present right next to the password field so in situations where you might need to, you can switch the password to a string of •••• instantly.

Similar patterns have also popped up in the LinkedIn app and Internet Explorer 10.

We wanted to try it in a hybrid mobile web app we’re currently building, but couldn’t find any open JavaScript implementations that were touch-optimized. So we made one.

hideShowPassword is a jQuery and Zepto plugin for… wait for it… hiding and showing passwords. Give it a whirl!

The coolest part about this plugin is the “innerToggle” option. When true, it will create a nifty hide/show control you can style as you like. It even maintains the input focus when tapped in a touch browser.

You can get the plugin or view the source on GitHub (also a great place to report issues or contribute improvements). We hope you dig it!

Update (March 21, 2014)

Check out Version 2 of hideShowPassword!

Tyler Sticka

Tyler Sticka is Cloud Four’s VP of Design, allowing him to think about design systems every day. When he isn’t directing his team, sketching on sticky notes or nitpicking CSS, he enjoys reading comics, making video games and listening to weird music. He tweets as @tylersticka.

Never miss an article!

Get Weekly Digests


Tyler, this is fantastic work. Thank you for doing it!

However, you undersell the challenges of getting the innerToggle to work on iOS.

For those who haven’t tried to build something like this, it was a tricky task to tap on that show/hide element and not have the keyboard go away on iOS.

There is a bunch of intelligent design in what Tyler has done to make sure it works as you expect. Even if you roll your own solution, it’s worth looking into how Tyler handled it. Very cool.

The eye thing is similar to windows 8. It’s interesting that in windows 8 the default is to hide, and only when you hold you see the password. It’s like a quick look.


Yep, first thing I thought of as well. Internet Explorer 10 also has this functionality built-in for all password fields. Hopefully the other browsers will notice and follow suit.

I also like how they implemented it to mask by default, but then with click and holding on the eye you can quickly check for any typos before submitting. Perfect for touch enabled devices.

The eye is for localization. Hide/unhide text string can run long when translated.



The winking eye is just one possible style. Text is inserted into the toggle element, which you can style as you like. You can also customize the text in the options. So if anyone’s adamant about using “verbergen” instead of “hide” for their German-language app, they have the option of doing so.

I was just asking the developers to bring hide/show pwd features in the WP logins and found http://wordpress.org/plugins/easy-to-use/ . But your work can be carried to any custom apps too. Thanks for the nice work and share.


Thanks! Something that WordPress plugin doesn’t do is offer an inner toggle control that maintains input focus on tap. That’s the biggest thing I wanted this plugin to be able to do.


Translating Tyler’s comment for those who haven’t dug into this in great detail, here is the problem.

Most of the show/hide password solutions I’ve seen incorporate a checkbox like the third example that Tyler’s plugin supports:

If you open that example in Mobile Safari, start typing a password. Now toggle the checkbox. What happens?

You lose the keyboard. You have to tap back into the input to begin typing again.

Contrast that to the behavior of the top two examples with the toggle inside the input element. You can hide and show passwords to your heart’s content without the keyboard going away and without you losing your place.

The reason the keyboard goes away is because when you tap on a different element, the focus moves from the input (which triggers the appearance of the keyboard) to the new element which hides the keyboard. Maintaining focus on the input while also triggering behavior and showing a button was the real challenge.

I’ve not seen any other open solution that does this in the browser.

Great plugin, but…

Just to let you know: I don’t like the color your “clicked” links get. As soon as you click any link it looks almost as if they are no links at all (actually your “unclicked” links are hard to see, too). Better go with some standards and – at least – give them an underline or make their color stand out a little more.

The Hide show password is clever indeed. I think it is a good addition, but in earlier discussions regarding this subject I believe that defaulting to hidden might be of interest as to not alarm users.

Also with the eye I must say that I consider it backwards. An open eye to me is an open eye. thus the open eye state would indicate that a password is visible. The closed eye would indicate that it is hidden.

David Stenbeck


If you instantiate the plugin but don’t specify whether or not to start it with a shown or hidden value, it will fall back to the “type” attribute of the input. If “password,” the input will remain hidden. If “text,” the input will remain shown.

I agree that the icon states could be interpreted as the current visibility state and not as the tap action. I decided to mimic the pattern adopted by the LinkedIn app and IE10/Win8 (open eye when hidden, closed eye when shown). I figured they probably did their homework.

If you view the demo source, you can see it’s just a CSS change to switch them if you so choose. Go wild!

The only reason I can think of to mask your password is if someone’s watching along. Presentations perhaps.

So then why is “visible” the default option? What if someone starts typing their password without thinking it’s vissible. You only need “corr” to social engineer that password into “correct horse battery staple”.

I’d suggest auto-hide and have the Hide/Show text available all the time, i.e. not just on :focus.

Gerben Jacobs


The default “show” value is not “true.” If you do not provide a value, it will fall back to the input type. If the type is “password,” the value will be “false”.

By default, the inner toggle is shown as soon as it’s instantiated. It’s only hidden if you provide an event name for the “hideToggleUntil” option.

View the demo source for examples of both of these in action.

Good idea but IMO the default is bass ackwards.

I’m developing a password manager and use “peek” the exact same way but I chose to leave the initial entry masked. I’ve been known to have to get up to _____ and leave the display unmanned anf forgetting to disable peeking is all too easy if my bladder tells me its time to get up or else (lol) and I contend many of us do so too.

What I need to learn –now– is how a person can get a user name and password from a password manager running on a mobile phone and then use the user name and password with a mobile app that requires authentication.

Remembering the data doesn’t work and I don’t thinki we have a clipboard on phones so how is this getting done?

I’m all ears for opinions and practices on that context…

Let’s discuss your project! Email Us