Nested Custom Fields (Hierarchical Field Containers)

I’d like to propose support for nested custom fields or field containers in Bitwarden vault items.

Current Limitation:

To simulate structure, I currently use flattened, YAML-style key names in custom fields, like:

  • email.address
  • email.alternative
  • license.holder.name
  • license.valid_until
  • license.code
  • license.note
  • recovery.phone.number
  • recovery.email.address
  • recovery.code.1.value
  • recovery.code.1.used
  • etc.

This works, but it becomes unwieldy and visually cluttered — especially when managing items with many logically grouped fields.

Proposed Solution:

Introduce a way to create container/group fields with a name, under which multiple related custom fields can be nested. Ideally, the UI would:

  • Allow expand/collapse of these containers for clarity.
  • Maintain structure in exports by flattening nested keys using dot notation (e.g., email.address, license.valid_until).
  • For CLI tools and APIs, treat nested keys as flattened keys.

Benefits:

  • Enhances readability and organization for complex items.
  • Reduces noise when working with large sets of custom fields.
  • Improves semantic grouping, making items easier to understand and maintain.

This would be especially useful for users who treat Bitwarden as a secure, highly structured knowledge base, not just a credential store.

Thanks for considering!

How would this interact with autofill. One of the primary uses for custom fields is to autofill fields that the default rules miss. In those cases, the Bitwarden field name must exactly match webpage fieldname so it knows what to fill.

1 Like

There is a different feature request (proposing user-friendly labels for custom fields), which offers a possible solution for how to maintain autofill functionality:

1 Like