Remove/increase 1000 character password/field limit length

I was moving entries from Keepass to Bitwarden, but I couldn’t insert my SSH encryption key (4096 characters) because the limit for the password field is 1000 characters, and custom fields cannot have >1000 either, so I have to store it in the Notes section.

I’ve since reencrypted my SSH keys using 687 character passwords (it seems I can’t even get 1000 characters), but it would be preferable to not have such restrictions. I’d be fine with having this restriction only applying to the free version if space is a concern.

On another note, why can’t I get to 1000 characters? 688 is the real limit. I’ve even tried only using a-zA-Z characters just to make sure it wasn’t having to escape any special characters, and I still can’t get past 687 characters.

The server limit is on the encrypted length of the data, not the unencrypted. We probably need to make the error message more clear.

Large data is better suited as file attachments rather than storing them in fields.


We would also like to see character limits increased to double what they currently are. File attachments are not very usable or searchable, so they are not a good option. Secure notes in particular would be nice to have a 20000 character limit?


This was a problem when I tried to migrate from Chrome by importing the csv file it generates, as it simply gave an error and cancelled the action. I had to manually edit the csv and look for the problem, since the manager didn’t even bother to tell me what entry was exceeding it, and it didn’t let me just ignore it and import the rest (it was a token that an Android app stored). Either way, it wouldn’t have been a problem if the limit was higher.
This feature request was recently linked on this github issue (it had diverged from the original issue to this). You can see other use cases that require a higher limit listed there, such as k8s tokens and ssh keys.


See also and friends.

1 Like

Hi, I just migrated to Bitwarden and cannot store my K8s tokens to connect to dashboard, which is a shame.

Please review this limitation as there is real use cases for that.


With the influx of LastPass users, this should be seriously considered.


Yes, storing a private SSH key unencrypted/plaintext feels wrong somehow…


This very well may be a deal breaker. SSH keys, secure notes for clients, all sorts of different use cases. This is urgent!


A solution for this is on the roadmap this half of the year.


I am currently doing a PoC for my organization and ran into this. This is a deal breaker. Could you please be more specific about when and what you are going to implement? I don’t have a strict deadline of implementation but I would need some assurances in order to keep considering Bitwarden as a solution.

Standard fields will be increased to 5k characters, which should cover this use-case :+1:

Standard fields? So not the designated and encrypted password field?

Custom fields will support it:

1 Like

Are custom fields stored as hashes or plane text on the server?

Everything is encrypted before it leaves your device, regardless of client.

Here are some helpful links about our security implementation:

  1. Vault Data
  2. Encryption
  3. Account Encryption Key
  4. Account Fingerprint Phrase
  5. Storage
  6. Compliance, Audits, and Certifications
  7. Emergency Access
  8. Privacy when using Website Icons
  9. Security FAQs
1 Like

Thank you.

If the custom fields are handled the same as the password field then I just wonder why you don’t allow longer secrets in the password field. This is not an edge case for businesses! We as an Enterprise have hundreds of secrets which would need to make use of this workaround. I don’t consider this a solution as it introduces inconsistencies and I don’t even think this is practicable as a workaround. We have thousands of secrets which we would like to migrate from dozens of Azure key vaults to Bitwarden. We need a history for those secrets as well! We also want to automate some processes and having some secrets in another field than the password field is not going to work for us.


@tgreer I want to second @Xentrax’s request. Just increasing the limit for custom fields (and not the password field) will not work for us. We have Kubernetes Dashboard secrets with a length of I think ~1500 chars which have to be stored in the password field in order to get them auto-filled.

You should still be able to use autofill with the custom field so long as you name-match it. See:

Auto-fill Custom Fields

The Name specified for a custom field is critical to successfully setting up auto-fill for custom fields. When naming the custom field, you should use one of the following HTML form element attributes/values:

  1. HTML form element’s id attribute.
  2. HTML form element’s name attribute.
  3. HTML form element’s corresponding label value.
  4. HTML form element’s aria-label attribute.
  5. HTML form element’s placeholder attribute.

Bitwarden will search the matched-URI webpage for those HTML form element attributes/values in the above priority-order. If a custom field’s name matches one of those attributes/values, auto-fill will be available into that HTML form element.

But I agree this feels like an unnecessary palaver. The new higher limit should apply to all fields.

1 Like

Thanks, @Thames. I wasn’t aware of that. That would be at least a workaround.
Although I feel the same as you that this is not as comfortable as having the password field with the increased limit.

1 Like