The Jira custom field limit in Jira Cloud is 700 fields per space, counted from the fields in the field configuration schemes linked to that space. There's no limit on the total number of custom fields across the site, and trashed fields don't count. Work types have their own limit of 150 per space.
Per space, not per site
Atlassian now enforces a limit of 700 fields per space in Jira Cloud. Atlassian calls them spaces now; older guides say projects. The count comes from the fields in the field configuration schemes associated with that space. Across the whole site, there's no limit on how many custom fields can exist.
The detail that matters is shared fields. A field counts toward every space whose schemes include it. So a company-wide field like Customer or Region, added to the schemes of ten spaces, counts once in each of those ten.
The limits now enforced, and the ones coming
| Item | Limit | Applies to |
|---|---|---|
| Fields per space | 700 | Enforced now |
| Work types per space | 150 | Enforced now |
| Field options per field | 20,000 | Being enforced progressively |
| Work item security levels per space | 50 | Being enforced progressively |
| Permission grants per permission | 50 | Being enforced progressively |
| Workflow statuses per workflow | 200 | Being enforced progressively |
| Total custom fields on a site | No limit | Site-wide |
Atlassian is rolling out eight more limits progressively. Beyond those in the table, they include 15000 releases per space, 150 workflows per workflow scheme, 10,000 Jira components per space and 100 priorities per space.
What happens when a space hits 700
Nothing breaks. Jira stops an administrator from associating more fields or work types with that space until usage comes down. Your existing configuration keeps working, and Jira doesn't delete anything automatically. The impact is on admins making changes, not on the people using the space day to day.
Freeing up headroom
Atlassian Support points out that trashed fields don't count toward the 700. So the first job for a space near the limit is often a tidy-up: move unused fields to the trash and the count drops. Then look at shared fields. If a field sits in a space's schemes but nobody in that space uses it, removing it from those schemes frees a slot there without touching the other spaces.
Admins can review and simplify their data shape in Jira admin settings or with Site Optimizer, which is the place to start on a large or older site.
A worked example
Say your site has 40 company-wide fields that live in every space's schemes, and your marketing space adds 300 of its own. That space is at 340, well clear of the limit. Now picture an engineering space that has collected 650 fields of its own over the years. Add the 40 shared ones and it's at 690. One more team request for a dozen fields and the admin can't add them. The fix isn't to remove the shared fields everywhere. It's to trash the engineering space's dead fields, which only affects that space.
Limits versus guardrails
Atlassian separates enforced limits from guardrails. Going over a guardrail doesn't block an action automatically, but it may affect complexity or performance. Going over a limit, like the 700 fields, does stop the change. Treat guardrails as early warnings worth acting on.
Migrating from Server or Data Center
If you move to Cloud and your usage after migration is at or above 90% of a limit, Jira applies a three month temporary exemption for that entity. Below 90%, standard limits apply straight away. So a space close to 700 fields gets some breathing room, but the clean-up still has to happen.
Want AI doing the heavy lifting in your marketing?
I build the systems that handle the boring 80 percent, so you get your week back. Done properly, with the human kept in.
A lighter structure elsewhere
Linear documents project milestones and initiatives for organising work rather than custom field schemes. If your Jira setup has grown hundreds of fields, it may be worth asking whether you need them all. My roundup of Jira alternatives covers tools built around lighter structures.
My advice for Jira admins
Audit fields per space before you hit the limit, not after. Trash what nobody uses, remove shared fields from schemes where they aren't needed, and agree a simple rule for new fields so the count doesn't creep back up. Most spaces that approach 700 got there one well-meant field at a time. If you're newer to running projects, my guide to project management knowledge areas for beginners is a useful primer.
Want your tool on this list? Featured spots and reviews here are paid partnerships. Here's how to partner with me.
Frequently asked questions
How many custom fields can Jira have?
There's no site-wide limit, but 700 fields per space are enforced.
What happens at the limit?
Admins can't associate more fields with that space until usage drops. Existing setup keeps working.
Do trashed fields count?
No.
Is the limit the same for work types?
No. Work types have their own limit of 150 per space.
Does this affect Server migrations?
Usage at or above 90% of a limit gets a three month exemption.
