Long Text Area
A Long Text Area is the Salesforce field type for storing text up to 131,072 characters.
Definition
A Long Text Area is the Salesforce field type for storing text up to 131,072 characters. It is the larger sibling of the Text field (capped at 255 characters); admins pick Long Text Area when the field needs to hold extended prose like product descriptions, case resolution notes, custom audit logs, or any text content that exceeds the 255-character cap. The field renders as a multi-line textarea in Lightning Experience, supports basic plain-text content, and stores the value as-is without HTML or formatting.
Long Text Area fields differ from regular Text fields in several important ways beyond just length. They are not searchable by default (admins enable indexing per object), they don''t appear in standard list view filters, and they cannot be used in standard SOQL relationship queries. Long Text Area fields are the right choice for content storage and the wrong choice for searchable identifiers. The Rich Text Area field type is the alternative when formatted content (bold, italic, lists) is needed; Rich Text Area is built on top of Long Text Area with an HTML editor.
Long Text Area limits and behaviors that surprise admins
The 131,072 character cap
Long Text Area fields store up to 131,072 characters. The number is the same on every Salesforce edition. Storing approximately 130 KB of text per field per record is significant; multiply by row count to estimate storage impact. Salesforce caps the total per-record storage for Long Text Areas at the field-level limit; very large content needs an alternative pattern.
Search indexing is off by default
Long Text Area fields are not indexed for search by default. A user searching for content stored in a Long Text Area gets no results unless the admin enables indexing on that object. Setup, Object Manager, the relevant object, Fields & Relationships, find the field, edit, check Enable Long Text Area Search. The setting indexes every Long Text Area on that object, with storage and performance implications.
List view and report filter limitations
Long Text Area fields cannot be used in list view filters or report filters by default. Salesforce treats them as content fields, not query fields. The Contains operator is supported in some scenarios but with limited performance. For filterable text, use a regular Text field or extract searchable values into a separate field.
SOQL access
SOQL can return Long Text Area fields in SELECT, but with restrictions. Long Text Area cannot be used in WHERE clauses with the equals operator; LIKE is supported but slow. The recommended pattern is to query Long Text Areas only for display, not for filtering.
Rich Text Area as the formatted variant
Rich Text Area is a Long Text Area with an HTML editor. Users see formatting (bold, italic, bullet lists, images). The field stores HTML; the rendering layer parses it. Rich Text Area inherits all the indexing and filtering limitations of Long Text Area plus the additional consideration that HTML can be malicious if displayed without escaping.
Storage implications
Each Long Text Area row uses up to the cap plus indexing overhead if enabled. High-volume objects (Cases, Activities) with multiple Long Text Areas filled to capacity consume substantial storage. Plan storage growth conservatively; build cleanup processes for records that no longer need the full text.
Formula and validation access
Formulas can reference Long Text Area fields with limitations. Functions like LEN() work; some text-manipulation functions (LEFT, MID) work up to the formula''s 5000-character compile limit. Validation rules can use Long Text Area fields but cannot fire on very long content without hitting formula limits.
Configure a Long Text Area field correctly
Creating a Long Text Area takes a minute; configuring it correctly for the use case takes thought.
- Pick the field type carefully
Setup, Object Manager, pick the object, Fields & Relationships, New. Choose Long Text Area or Rich Text Area depending on whether formatted content is needed.
- Set the length and visible lines
Pick the length (up to 131,072). Set the number of visible lines (3-25) for the rendering height.
- Decide whether to enable indexing
If users need to search the content, enable Long Text Area indexing on the object. Be aware of storage and performance trade-offs.
- Add to page layouts
Place the field on the relevant page layouts. Position it where users naturally enter content (often below the standard fields).
- Configure field-level security
Set FLS per profile. Sensitive content in Long Text Areas should not be readable by all users.
- Plan storage growth
Estimate the average and maximum content size. Build cleanup workflows for fields that grow indefinitely.
Long Text Area or Rich Text Area.
Up to 131,072 characters; pick deliberately.
3-25; controls the rendering height.
Decides whether the field is searchable.
Controls per-profile read and write access.
- Long Text Area is not searchable by default. Enable indexing if users will search the content.
- List view and report filters do not support Long Text Area by default. Filterable text should go in a regular Text field.
- Storage adds up. Multiply 131,072 bytes by row count to estimate the worst-case storage impact.
- Rich Text Area stores HTML. Display layers must escape it correctly to avoid script injection.
Trust & references
Cross-checked against the following references.
- Custom Field TypesSalesforce Help
- Field Types ReferenceSalesforce Help
Straight from the source - Salesforce's reference material on Long Text Area.
- Object ReferenceSalesforce Developers
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. What is a Long Text Area field?
Q2. When use Long Text Area instead of Text?
Q3. What's a limitation of Long Text Area?
Discussion
Loading discussion…