Configscope

Find duplicate custom fields in Jira

Paste your custom field list to see which fields duplicate each other. Same-name fields do more than clutter a picker — they make JQL return the wrong answer. Everything runs in your browser.

1 · Paste your custom fields

One per line, name included — the name is what gets compared here. The id is optional but makes the output usable.

Custom field list

In Jira: Settings → Issues → Custom fields. Copy the Name column; ids come along if you paste the whole row.

2 · Duplicate groups

Grouped worst-first: exact name collisions come before near matches, and larger groups before smaller ones.

Download groups as CSV

Why same-name fields are a correctness problem, not a tidiness one

This is the part most cleanup advice leaves out. Two custom fields sharing a name will quietly break searches.

Atlassian has logged this. In JRACLOUD-77541, JQL gets confused when team-managed projects contain a field with the same name as another project's field — an issue that cannot hold a value for the other field still gets caught up in the evaluation. JRACLOUD-76482 covers the same shape of problem for EMPTY tests across projects. The workaround Atlassian gives is to stop using the name and query the field id instead: cf[10001] is not EMPTY rather than "Team" is not EMPTY.

So every duplicated name is a small trap: a filter, a board, a dashboard gadget or an automation rule written against the name may be reading a different field than its author intended, and nothing announces it. Consolidating duplicates fixes a class of silent wrong answers, which is a better reason to do it than saving space.

Where duplicates come from

1. Team-managed projects each create their own. A team-managed project makes its own fields, scoped to itself. Ten teams that each add "Severity" produce ten distinct fields with one name. This is the largest source in most instances and nobody did anything wrong.
2. Migration from Server or Data Center. Imports commonly land alongside existing fields rather than merging into them, often with a suffix like (migrated) or a trailing number.
3. Different admins, different years. "Customer Name", "Client name", "Customer" — three people solving the same problem without checking what already existed.
4. System fields shadowed by custom ones. "Story Points" and "Story point estimate" is the classic pair, and picking the wrong one breaks reports rather than boards.

Duplicates spend the same headroom as everything else

Atlassian caps fields at 700 per space, and flags a space once it passes 75% of that. A duplicate counts fully against the cap. Consolidating five fields into one gives back four slots in every space they were associated with — which is why merging duplicates is usually the cheapest headroom you can buy, ahead of deleting anything anyone might still want.

Confirm current values against Atlassian's data limits and guardrails documentation — Atlassian revises them.

Do not merge on the name alone

A shared name is a reason to look, not a reason to act. Before consolidating a group, find out which member actually holds data — the one with values is the one to keep, and the others are the ones to retire. Fields in a group frequently have different types, and a number field and a text field called "Estimate" cannot be merged at all.

The unused custom field checker generates the queries for that: run each member of a group, keep the one with the values.