Short definition
A label in Jira is a free-form tag attached to an issue, used for ad-hoc categorisation. Labels are created on the fly by any user with edit permission - no admin setup, no controlled vocabulary. Multiple labels can be applied per issue, and they're fully searchable in JQL via `labels = ...`. Labels are global across the instance, so the same label string is shared by every project that uses it.
Where labels fit
Labels are Jira’s lightest-weight categorisation tool. They sit alongside:
- Components - project-scoped, admin-managed, with default assignees.
- Custom fields - structured, admin-defined, can have controlled value lists.
- Versions - release-scoped, admin-managed.
- Labels - free-form, user-created, no admin overhead.
The defining trait is no governance: any user with Edit Issues permission can create a label by typing it, and the label exists from that moment on. This is great for ad-hoc tagging but terrible for long-term taxonomy hygiene.
What labels are good for
The use cases where labels genuinely outperform structured fields:
- One-off campaigns. “Tag all issues related to the 2026 outage post-mortem as
pm-2026-q1.” When the campaign ends, the label naturally falls out of use. - Cross-project flagging. A
customer-escalationlabel can attach to issues in any project; a component is project-scoped and can’t. - Personal organisation. Some teams encourage individuals to use personal labels (
alice-watching) for their own tracking.
In each case the value is that no admin had to set the label up. Labels are deployable in seconds.
Where labels go wrong
Same trait, opposite effect. Two failure modes:
- Sprawl. Labels accumulate forever. After three years a Jira instance has thousands of labels, most used once. Audit periodically and document the labels the team actually uses.
- Inconsistency.
tech-debt,techDebt,Tech Debt,tech_debtare all separate labels. JQL that filters on one misses the others. Pick a convention (lowercase, hyphen-separated) and document it.
When label sprawl becomes painful, the right answer is usually to migrate the heavily-used labels into a controlled-vocabulary custom field (Select List or Multi-Select). Custom Fields for Jira surfaces label usage frequency, which is the basis for deciding which labels deserve promotion to a structured field and which can be retired.
Labels in JQL
Labels are first-class in JQL:
labels = frontend- exact match.labels in (frontend, backend)- any of these.labels = frontend AND labels = api- both required.labels is EMPTY- no labels at all.labels is not EMPTY- has at least one label.
There’s no LIKE operator for labels - matches are exact. This is another reason capitalisation
discipline matters.
See also (Redmoon products)
Common questions
What is a label in Jira?
A label in Jira is a free-form tag attached to an issue, used for ad-hoc categorisation. Labels are created on the fly by any user with edit permission - no admin setup, no controlled vocabulary. Multiple labels can be applied per issue, and they're fully searchable in JQL via `labels = ...`. Labels are global across the instance, so the same label string is shared by every project that uses it.
Labels vs components - what's the difference?
Components are project-scoped, admin-managed, and have an owner (default assignee). Labels are global, user-created, and unmanaged. Use components for structured project taxonomy (modules, subsystems); use labels for cross-cutting ad-hoc tags ('regression,' 'customer-escalation,' 'tech-debt'). Most projects need both.
Are Jira labels case-sensitive?
Yes. `frontend`, `Frontend`, and `FRONTEND` are three different labels. This is the single biggest source of label-sprawl pain: someone capitalises differently and now there are two near-duplicate labels for the same concept. Conventions like 'all lowercase, hyphen-separated' are worth enforcing early.
How do I find all issues with a specific label?
JQL: `labels = frontend` returns every issue with that label. For multi-label queries: `labels in (frontend, backend)` is an OR; `labels = frontend AND labels = backend` is an AND. Note that `labels is EMPTY` finds unlabelled issues - useful for audits of label coverage.