Zuko Blog

Password Creation in Online Forms

Back to blog

This articles gives you detailed advice and best practice tips when asking users to create a password online.


When users create an account on your site, they will usually need to create a password. This, as far as online forms go, can be complex. You as the website owner want the password to be:

These three requirements often lead to password fields adopting some or all of the following approaches:

These techniques can lead to these fields being comparatively difficult for a user to complete successfully, and can therefore lead to use frustration.

Some Zuko data

We did some digging into some Zulo data since January 2020, specifically looking at how often users have to return to password fields.


From the above we can see that, on average, almost 50% of sessions have to return to a password field after exiting it, and when they do return they do so an average of twice. In other words, 1 in every 2 people that try to set a password on the above sites get it wrong twice and only move on after the third attempt. That’s a significant amount of friction being put in the way of users.


Even in the best performing fields above, over 30% of users have to return to the password field at least once.


Similarly the lowest average number of field returns was over 1.5 times.

Minimum length and complexity requirements

Short and simple passwords are easier to crack. Sites therefore have traditionally taken steps to force users to create passwords that contain a certain degree of length of complexity. 

For example:


In the above, I have four different requirements on my password that I set. If any of them is not met, I have to choose a different password.

Baymard Institute lists two potential downsides to overly strict password requirements:

  1. Users get frustrated with the password creation process itself. While this is frequently observed, we rarely see it causing abandonments, so long as the password requirements are communicated clearly upfront.
  2. When users are forced out of using their “standard” passwords, they later on are very prone to have difficulties remembering it, and, hence, very frequently experience sign in issues on subsequent visits. This is the true cost of imposing more strict password requirements.”

The first point consistent with data taken from Zuko - 50% of users return to the password field at least twice. This is a significant point of friction for users, and has a detrimental effect on UX.

Baymard also highlights the fact that since a f0rm may require a complex password, a user may ‘make up’ a particularly complex one and, without a password manager, simply not be able to log in further down the line since it would be almost instantly forgotten. The password reset function would therefore be used widely, which is not a great user experience.

The Information Commissioner's Office in the UK provides some clear guidance on password requirements:

“There are three general requirements for any password system that you will need to consider:

  1. password length—you should set a suitable minimum password length (this should be no less than 10 characters), but not a maximum length. If you are correctly hashing your passwords, then the output should be the same length for every password, and therefore the only limit to password length should be the way your website is coded. If you absolutely must set a maximum length due to the limitations of your website code, then tell users what it is before they try to enter a password;
  2. special characters—you should allow the use of special characters, but don’t mandate it. If you must disallow special characters (or spaces) make sure this is made clear before the user creates their password; and
  3. password blacklisting—do not allow your users to use a common, weak password. Screen passwords against a ‘password blacklist’ of the most commonly used passwords, leaked passwords from website breaches and common words or phrases that relate to the service. Update this list on a yearly basis. Explain to users that this is what you are doing, and that this is why a password has been rejected.

Other than the three requirements listed above, do not set restrictions on how users should create a password. Current research (see ‘Further reading’ below) indicates that doing so will cause people to reuse passwords across accounts, to create weak passwords with obvious substitutions or to forget their passwords. All this places unnecessary stress on your reset process.”

Microsoft also recommends avoiding complexity requirements, so despite them being a very common feature of online forms, they are hard for humans to remember. If you need further evidence, this XKCD comics summarises the issue well:


In short, password length requirements are fine (and good), but complexity requirements have a detrimental effect on user experience, and are unnecessary. 

Inline validation (with a difference)

Whichever approach you use to enforcing password length and complexity, password fields offer you a chance to implement instant inline validation.

Rather than wait until the form is submitted, you can provide real time feedback to make sure you are letting users know how close they are to meeting your requirements.

This gives instant feedback, and does not punish a user for getting it wrong - instead it guides them to getting it right.

Password, confirm password

So a website wants you to be able to login after creating an account with a sufficiently long/complex password. So in order to make sure you set and remember the ‘correct’ password, often you’ll be asked to confirm your initial password entry:


The logic goes - since you entered the password twice, you’ll be twice as likely to remember the password upon your return.

There are a number of problems with this approach.

  1. If the passwords are masked, and your password entry does not match, you cannot tell where you made your mistake:

You therefore have no way to correct either field. You simply have to delete both and try again, hopefully getting it right the second time around.

  1. The first point is compounded by complexity requirements, where onerous additions to passwords will may it all the more likely that a user makes mistakes that they are unable to correct.


  1. Any additional fields within a form take time and effort to complete, even if done correctly. You want to be minimising the amount of mental energy required to complete a form, not adding to that total amount. This field will likely affect your conversion rate.

Take the fields mentioned previously fro Zuko that are confirm password fields:

They still are returned to often and create significant friction. 

The password confirm field is worth cutting.

Masking/Unmasking passwords

One way to help users reduce the amount of errors, and meet password requirements more easily, is to allow them to view the characters they are entering into a password field. 

For example, they might be able to to click an icon to the right to unmask the field:




Or a more explicit toggle option to show the password:




Dr Jakob Nielsen argues that we should show most passwords as text when we type them. His article, Stop Password Masking, has the following summary:

Usability suffers when users type in passwords and the only feedback they get is a row of bullets. Typically, masking passwords doesn’t even increase security, but it does cost you business due to login failures.

Dr Nielsen also points out two side effects of masking passwords, one of which lowers security:

Users make more errors when they can’t see what they’re typing while filling in a form. They therefore feel less confident. This double degradation of the user experience means that people are more likely to give up and never log in to your site at all, leading to lost business. (Or, in the case of intranets, increased support calls.)

The more uncertain users feel about typing passwords, the more likely they are to (a) employ overly simple passwords and/or (b) copy-paste passwords from a file on their computer. Both behaviors lead to a true loss of security.

Dr Nielsen concludes that ‘It’s therefore worth offering them a checkbox to have their passwords masked; for high-risk applications, such as bank accounts, you might even check this box by default. In cases where there’s a tension between security and usability, sometimes security should win.’

Data taken from Zuko supports this:



Sessions that interact with unmasked password fields return to them at a far lower rate.

Zuko data also suggests that a relatively low number of people choose to unmask their passwords. This may be due to the UI being too subtle or ambiguous with users not knowing how to use the functionality.


We would support having the ability available, and testing out different implementations on your website visitors.

Alternatives which maintain levels of security

When reducing complexity requirements

Is it possible to reduce the password requirements without sacrificing security? From Baymard Institute again:

  1. While strong passwords can be particularly important for devices and applications where hackers have unlimited attempts, websites can implement security measures against such attacks by imposing password attempt obstacles and limitations. This removes the potential for brute-force attacks and hence the need for highly complex passwords.
  2. At e-commerce sites we can greatly minimize the consequences of an account breach by not allowing account users to pay with a stored credit card if sending the order to a newly added or edited address (i.e. an address added by a hacker) – without first retyping some of their credit card details. Without the ability to send items to new addresses using a stored credit card, the hacker’s breach of the user’s account becomes less of a security concern, as the severity of the breach is greatly reduced.

More radical approaches

Magic links

A magic link is a unique URL sent to the email account you registered with. Each time you came to login, a new, unique link would be sent to your email address. Clicking the link would log you in, instantly. 

Since you use a password to access your email, and if accessing on a device you would also need to unlock it via a fingerprint or passcode, the security is effectively being outsourced to your email account.

You would therefore not require the setting of a password at all in the account creation process.

Monzo uses this method to allow you to log in, and below are a couple of articles discussing potential implementation of this approach.

https://hackernoon.com/magic-links-d680d410f8f7

https://medium.com/@kelvinvanamstel/should-we-embrace-magic-links-and-leave-passwords-alone-c73db7007fc4

Some discussion of the downsides - https://adam.ac/blog/magic-login-links-are-not-ok/

Codes to phones

Similar to the above, but instead of using email as the identifier, you would use a phone number instead.

Concluding Summary

Pulling this all together, here are our recommendations when designing and implementing password fields:

More from our blog:

Asking about Disabilities and other Sensitive Information in Online Forms
Do you need to ask users some sensitive questions in your online form? Here are a few pointers.
Benchmarking - Deep Dive into eCommerce
We look in detail at purchase forms at the eCommerce sector and draw out some of the key stats for you, as well as learnings you can take from our becnhmarking data.
Web form design lessons from examples of high converting forms
What can you learn from some of the highest converting forms in Zuko?
Zuko Benchmarking Data - Comparing Form Types
Some highlights from our benchmarking data, comparing different form types against each other.
Zuko c/o Formisimo Ltd, 5th Floor, Arrive, White Tower, MediaCityUK, Salford, M50 2NT
VAT Number: GB181252425
Registered in England as company number 08859680
New Business: sales@zuko.io
Support: support@zuko.io
Telephone: +44 (0)800 772 0982
This website stores data such as cookies to enable important site functionality including analytics, targeting, and personalization. By remaining on this web site you indicate your consent.