Recommendations on HTML Form Input Field Lengths (e.g. username, e-mail)

Question

Are there any guidelines/recommendations on how long the input fields should be on HTML forms. Specifically:

• Viewable length (the length of the input field the user can see on the screen - without having to scroll horizontally. i.e. SIZE, not MAXLENGTH)
• Capture length (the number of characters the HTML form will save to the database)

The viewable length could be short (20 characters), but does that frustrate users with slightly longer e-mail addresses?

The capture length could be set to 200 characters for all fields, but is that good practice? Would there be any disadvantages for this?

The common fields that I am thinking of are:

• Name
• Username
• Password
• E-mail address
• Users website address
• OpenID address
• Location (e.g. town and country)

Fields with known possible values (such as age, telephone number, country, manufacturer) can all be pre-judged so are not an issue.

Answer 1

You can keep them same or slightly less than the database field lengths assuming that these are eventually going to be stored.

Answer 2

There should be no difference of viewable/capture length. At least I never heard of that approach, which I find very strange.

Names in some cultures can be very different, several hundred characters very easily.

Login name could be within the limit of 30 characters, this is the Google's limit.

Passwords should be hashed and never stored directly, hashes make 40 characters.

Emails can be up to 260 characters long. If you take into account the possibility of non-Latin characters, the substitutes for such characters will further expand this length.

Telephone number and postal codes are far from being predictable, lengths and format vary significantly from country to country.

My suggestion for you is to use unrestricted fields in the database. If you are with SQL Server, then use nvarchar(max). You can introduce restrictions in your code, but be prepared to expand them whenever a user complains to you that he cannot enter his/her information correctly because of your limitations.

Answer 3

I tend to make them very long - 200+ characters. Making the values more readable when displayed in the site is secondary to actually stopping people being able to put their own email address in.

Considering your back-end database most probably has a type that allows strings up to a certain length but doesn't punish you by storing 200 characters if you only store 10 in there, I don't see any down-sides to this approach.

I am talking specifically about fields such as email, name, address, website url but not things like username and password which are things you will need to have a sensible limit on as your app needs to work with them. IE, if you are asking the user to enter data that belongs to them, you should never print the following type of validation message:

"Sorry, your name/email-address/thing-we-need-from-you is too long, you can't enter it."

Answer 4

I actually found this question while searching for an answer myself... after reading through the first batch, I have a couple of suggestions:

1. If you're creating the data for your application, the data-field length should match the viewable size; particularly for things like a User-ID. This is something you control.

2. Password fields should have as large an upper-limit as you're willing to accomodate. Since the password itself shouldn't be stored (store a hash) the field on the form could represent something around 1.5x - 2.0x the minimum permitted length (after all, it'll be obscured with * anyway.

3. The tricky part is peoples' established information. If the majority of your user-base comes from a single jurisdiction, than you can optimize for that case and you could have an "other" option for people in other localities, or simply allow the field to be blank depending on your implementation.

Bottom line: make the fields as short as you can but still permit the majority of your targeted audience to fill in the form; and decrease complexity by not collecting any information that you don't absolutely require.