Cloud Four Blog

Technical notes, War stories and anecdotes

16 Comments on “Hide/Show Passwords: The Missing Plugin”

  1. Jason Grigsby says:

    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.

  2. Chris Poteet says:

    I like this, but isn’t the eye icon unnecessary. Why not just use text?

  3. Surui says:

    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.

  4. LukeW says:

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

    • Tyler Sticka says:


      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.

  5. Benny says:

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

    • Tyler Sticka says:

      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.

      • Jason Grigsby says:

        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.

  6. Dominik says:

    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.

  7. David Stenbeck says:

    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.

    • Tyler Sticka says:

      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!

  8. Gerben Jacobs says:

    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.

    • Tyler Sticka says:

      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.

  9. 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…