Answer eight questions about one field. Three of them cover cases where an empty-looking field is not empty and deleting it destroys data. Everything runs in your browser.
Answer the checks below to get a verdict.
A zero issue count is where this starts, not where it ends.
The checks
"Don't know" is a legitimate answer and is treated as a reason to stop, not as a pass.
Check
Answer
No verdict yet
Answer the checks above.
The three ways a zero lies to you
Counting issues that hold a value is the right first filter — it is the only signal that tells you whether deleting the field loses data. But it has exactly three documented blind spots, and all three produce the same dangerous result: a field that looks empty and is not.
Fields owned by Marketplace apps. Atlassian has a logged defect, ECO-1401, where a string field belonging to a Forge app is treated as empty once its value passes roughly 285 characters. The data is there; the search says it is not. Fields that belong to apps rather than to you should never be deleted on a count alone.
Archived projects and archived issues. Jira's own custom field optimizer does not count archived issues or archived projects — admins have reported it returning zero for fields that are populated in archives. If you archive anything, treat a zero as "zero in the part I can see".
Same-name fields confusing the query. Under JRACLOUD-77541 and JRACLOUD-76482, JQL gets confused between same-named fields in different projects. Query by field id — cf[10001] — not by name, or the count you read may belong to a different field entirely.
And the way attachment lies to you — in the opposite direction
This one is worth knowing because it is what most cleanup tools run on, Jira's own included. Their criteria for "unused" are, verbatim from Atlassian's documentation, fields that "aren't in a space or a screen, or have no defined contexts", and on the site-level card, fields that are global and "not associated to any company managed space or screen".
Read that carefully and two failure modes fall out:
A field used in many projects often has no project-specific context — just the global default. "No defined contexts" catches it, and it gets offered up for deletion while thousands of issues depend on it.
The association check covers company-managed spaces and screens. A field living only in team-managed projects is associated with no company-managed space, so it lands in the unused list while a team uses it daily.
The asymmetry is the point. Deleting a field with no attachment but four thousand values destroys four thousand values. Deleting a field with zero values destroys nothing. Counting values is not the more thorough test — it is the safer one.
What to do with a verdict of "verify first"
Get the count properly. Query by id with a bounded clause: cf[10001] is not EMPTY AND created > "1970-01-01". The unused field checker generates these for a whole list.
Search your filters for the name. Saved filters, board configurations, dashboard gadgets and automation rules reference fields by name and break silently. There is no built-in report for this; searching your filter list for the field name is the crude version.
Check for a duplicate you should merge instead. If a near-identical field holds the data, consolidating beats deleting. The duplicate field finder groups them.
Trash, don't purge. Jira's own bulk removal moves fields to trash rather than deleting outright, and records the action in the audit log. Whatever route you take, keep the reversible one.