Quick reference for the column and content type limits that cause real problems in SharePoint Online lists and libraries.
| # | Limit | Value | Practical impact |
|---|---|---|---|
| 1 | Total columns per list or library (all types including system) | 2,000 | Hard ceiling; SharePoint blocks new column creation once reached |
| 2 | Recommended user-created column ceiling before performance degrades | ~300 | No hard error; views, forms, and API calls slow noticeably beyond this |
| 3 | Indexed columns per list or library | 20 | Hard limit; cannot be increased by admins or Microsoft support |
| 4 | Lookup columns per list before query performance degrades | ~10-12 | Soft limit; each lookup to a large list adds LVT query overhead |
| 5 | Column internal name character limit | 255 characters | Set at creation; cannot be changed; affects REST API URLs |
| 6 | Content type columns: contribution to list column total | All columns in the CT | Each CT applied to a list adds all its columns to the list schema, counting toward the 2,000 ceiling |
Limit 1 and 2: The Column Ceiling and the Effective Limit
SharePoint Online allows up to 2,000 columns per list or library when counting all column types: user-created site columns, content type columns, and SharePoint's internal system columns. System columns alone account for 30 to 50 columns depending on the list template, so the practical ceiling for user-defined columns is closer to 1,950. That still sounds generous.
The problem is that performance issues appear well before the hard ceiling. Lists with more than 300 to 400 user-created columns begin showing measurable slowdowns in view rendering, form loading, and API response times. No hard error appears at this threshold - the slowdown comes from the volume of column metadata SharePoint processes on every page render and query. Admins who build complex document management lists with dozens of metadata columns, then apply several content types (each adding their own columns), can reach the performance-degradation zone without ever approaching the 2,000 hard limit.
Regularly auditing unused columns from a list is good hygiene. SharePoint's native list settings page shows all columns and allows deletion of user-created ones, but there is no built-in report showing which columns have never been populated. Columns inherited from a content type cannot be deleted from the list individually; the content type must be removed from the list first.
Limit 3: The Indexed Column Cap
Indexed columns are the mechanism SharePoint uses to support filtered views on large lists without triggering the List View Threshold. When a column is indexed, SharePoint maintains a separate index structure for that column, allowing filtered and sorted queries to run efficiently even when the list exceeds 5,000 items.
The limit is 20 indexed columns per list or library. This is a hard platform limit that cannot be raised. Twenty sounds like a lot until you consider that a complex document management list might need indexes on: Modified date, Created date, Modified By, Document Status, Project, Department, Document Type, Approval Status, and several custom metadata columns. Running up against this limit forces a choice between which queries get indexed support and which will hit the LVT when the list grows.
Limit 4: Lookup Column Overhead
Lookup columns link a list item to a value in another list, pulling through a related field as a read-only reference. They are common in content management scenarios: a document referencing a project record in a projects list, or an invoice item linking to a supplier in a suppliers list.
Each lookup column adds a cross-list query to every view that displays it. When the referenced list is large (over 5,000 items), that query is subject to the List View Threshold on the referenced list. Multiple lookup columns compound this effect: a list with 10 lookup columns each referencing a different large list generates 10 separate cross-list queries on every view load.
Microsoft documentation advises caution when exceeding 10-12 lookup columns per list. There is no hard error at that point, but view performance degrades measurably. If a list design requires many lookups to large reference lists, consider whether some of those relationships can be resolved at data entry time (storing the looked-up value directly in a plain text column) rather than computed dynamically on every view load.
Limit 5: Column Internal Names
Every SharePoint column has two names: the display name (which you can change later) and the internal name (set at creation and permanent). The internal name is used in REST API calls, PnP PowerShell scripts, SPFx solutions, and Power Automate flows. You cannot change a column's internal name after creation - the only option is to delete and recreate the column.
The internal name is derived from the display name at creation time, with spaces replaced by _x0020_ encoding and special characters URL-encoded. A column named "Project Owner Name" gets an internal name of Project_x0020_Owner_x0020_Name. Any script or API call referencing that column must use the encoded form.
This creates a governance problem in unmanaged tenants where columns are created with verbose display names, changed repeatedly, and then referenced in automation built against the internal name. The fix is to establish a naming convention for site columns before deployment rather than after, and to create all site columns via the Content Type Hub or PowerShell with an explicit internal name defined at creation time.
Limit 6: Content Type Columns and the List Column Total
When you apply a content type to a list, every column defined in that content type is added to the list's column schema. The list does not store separate column sets per content type. All content type columns from all applied content types exist as columns in the list, and all count toward the 2,000 hard ceiling.
A content type hierarchy adds further complexity. A content type that inherits from a parent content type inherits all parent columns as well as its own additions. Applying a deeply inherited content type to a list can add a large number of columns at once, even if most of them are rarely used on that specific list.
For lists that need to support many content types, auditing column overlap between content types before applying them helps avoid unnecessary column accumulation. If two content types both define a "Department" column, each adds a separate column to the list (unless both reference the same site column from the site's column gallery). Using shared site columns across content types reduces redundancy and keeps the list column count lower.
Learn how Explore Master surfaces hidden column and content type properties
Frequently Asked Questions
Can you increase the indexed column limit beyond 20 in SharePoint Online?
No. The limit of 20 indexed columns per list is a hard platform limit in SharePoint Online that cannot be increased by tenant admins or through Microsoft support. If a list requires more than 20 indexed columns to support its views without hitting the List View Threshold, the list architecture should be reconsidered: splitting content into related lists or restructuring the data model is the recommended path.
What happens when a SharePoint list reaches the maximum column count?
SharePoint blocks new column creation once a list reaches its column ceiling. The error appears whether you add through the browser UI, PowerShell, or the SharePoint API. Existing columns and content types continue to function. Remediation options are to delete unused columns to free up capacity, or to restructure the list by moving some columns to a related list linked via a lookup column.
Do content types added to a list count toward the list's column limit?
Yes. Every column in a content type is added to the list's column schema when that content type is applied. A content type with 15 columns applied to a list that already has 200 user-created columns brings the list to 215 columns plus system columns. Each additional content type with unique columns increases the count further. Lists with many content types can approach the column ceiling faster than expected, particularly when content types use deep inheritance chains.