Long Text Area
A Long Text Area is a Salesforce custom field type that stores multi-line plain text up to 131,072 characters (128 KB).
Definition
A Long Text Area is a Salesforce custom field type that stores multi-line plain text up to 131,072 characters (128 KB). It is the larger relative of the Text field, which caps out at 255 characters. Admins reach for a Long Text Area when a field has to hold extended content like product descriptions, case resolution notes, meeting summaries, or any prose that runs past the short Text limit. The field shows up as a multi-line box in record pages, stores the value as entered, and keeps no HTML or formatting.
When you create the field you set its character limit. The default is 32,768 characters, the minimum you can pick is 256, and the ceiling is 131,072. Long Text Area behaves differently from a short Text field in ways that matter. It is not indexed for search the same way, it does not appear in standard list view filters, and it has narrow support in report filters and SOQL WHERE clauses. The Rich Text Area field is the formatted cousin, built on the same storage but adding an HTML editor for bold, lists, images, and links.
How Long Text Area stores, limits, and surfaces text
The character limits you set per field
Every Long Text Area field carries a length you choose at creation time. The default is 32,768 characters, which is 32 KB. You can set it as low as 256 or as high as 131,072 characters (128 KB). The number you pick is the hard cap for that one field. A user who tries to save more text than the limit allows gets an error and the record will not save. These same limits apply across every Salesforce edition, so the ceiling does not change when you move from Enterprise to Unlimited. There is also an object-level budget to respect. A single object can hold up to 1,638,400 characters in total across all of its Long Text Area and Rich Text Area fields combined. That total is what governs how many big text fields you can stack on one object. You can add many Long Text Area fields to an object, subject only to your edition's overall custom field cap, but their combined declared lengths count against that 1.6 million character pool. Plan the lengths deliberately so you do not exhaust the budget on fields that rarely fill up.
Search behaves differently than short text
A short Text field is searchable out of the box. A Long Text Area is treated as content, so admins need to be deliberate about how its text becomes findable. Global search and SOSL do index Long Text Area content, but the field is not something users can reliably filter on the way they filter a Text field. If you expect people to look up a value, store that value in a dedicated short Text field instead of burying it inside a long block. A common pattern is to keep the full narrative in the Long Text Area and copy a short key (an order number, a reference code, a customer name) into a separate searchable Text field through a formula, Flow, or trigger. That split gives you the best of both: a place for the long content and a clean, fast field for lookups. Treat the Long Text Area as the place text lives, not the place text gets queried. When you design the object, decide up front which snippets need to be searchable and surface those separately so users are not frustrated by a field that holds the answer but will not return it.
List views and report filters are restricted
Long Text Area fields do not show up as filter options in standard list views. Salesforce classifies them as content fields rather than query fields, so you cannot build a list view that filters records by what sits inside the long block. Reports are similarly limited. In a report filter, the contains operator only evaluates the first 254 characters of a Long Text Area or Rich Text Area value. Text past that point is ignored by the filter, so a match buried deep in a long field will not be found. Reports also display only the first 999 characters of the field in the output, which means long values are truncated in the report view even when the full text is stored on the record. These limits are a frequent surprise. An admin builds a report expecting to filter on a phrase, the phrase happens to fall after character 254, and the report silently returns nothing. The takeaway is the same as with search: if a value drives filtering or reporting, it belongs in a short field, and the Long Text Area should carry the bulk narrative that humans read rather than machines filter.
SOQL access and WHERE clause limits
You can put a Long Text Area field in the SELECT list of a SOQL query and get the full value back, which is the normal way to read the content in Apex or an integration. Filtering on the field is where the restrictions bite. Long Text Area fields cannot be used with the equals operator in a WHERE clause, and they are not allowed in ORDER BY or GROUP BY. The LIKE operator is supported, so a query can match a substring, but matching against a 128 KB column is slow and does not use an index. For any query that runs often or against a large table, filtering on a Long Text Area is a performance trap. The recommended approach is to query these fields only for display or processing, never as the thing you filter or sort on. If you need to find records by their text, extract the searchable part into an external ID or indexed Text field and filter on that. Keep the Long Text Area as the payload you retrieve once you already know which record you want.
Rich Text Area as the formatted variant
Rich Text Area is a Long Text Area with an HTML editor layered on top. Users get formatting controls for bold, italics, bullet and numbered lists, hyperlinks, and inline images. The field stores HTML markup, and that markup counts toward the same 131,072 character limit, so the tags themselves eat into the space available for visible text. Because it shares the underlying storage, Rich Text Area inherits the same search, filter, and SOQL constraints as plain Long Text Area. You can convert a Rich Text Area field into a Long Text Area field, but doing so strips the markup and deletes any images the next time the record is saved. The reverse conversion is not offered. Pick Rich Text Area only when the formatting genuinely earns its keep, such as customer-facing knowledge content or templated notes that need structure. The HTML adds parsing overhead and a security angle, because stored markup displayed without proper escaping can carry script. When formatting is not required, plain Long Text Area is the simpler and safer choice.
Storage planning and cleanup
A Long Text Area filled to 131,072 characters holds roughly 128 KB of text. On a small object that is trivial, but multiply it by a high-volume object and the math changes fast. Cases, Tasks, custom logging objects, and integration staging records often carry several long fields packed with verbose content. A field that big across a few million rows adds up to real data storage. Salesforce counts records against your org's data storage allocation, and oversized text contributes to that consumption. Size the impact before you deploy by estimating the average fill, not the maximum, since most fields never reach the ceiling. Then build a way to keep growth in check. Archival jobs that move stale narrative to an external store, scheduled flows that clear notes on closed records past a retention window, and policies that cap what users paste in all help. The character limit you set on the field is also a lever: do not declare 131,072 if the content never exceeds a few thousand, because the declared length affects the object's shared text budget and signals intent to anyone who reads the schema.
Formulas, validation, and the visible lines setting
Long Text Area fields interact with formulas under tight constraints. A formula can reference the field, and functions such as LEN work, but formula fields compile against a character ceiling, so long content can push a formula past its limit and cause errors. Text functions like LEFT and MID can operate on the field but only within the formula engine's bounds. Validation rules can read a Long Text Area, yet rules that scan very long values risk hitting the same formula limits, so keep any logic that touches these fields lean. On the display side, the field has a # Visible Lines setting that controls how many rows of the text box render on the record page. It changes the height of the input area, not the stored capacity, so a field set to four visible lines still holds the full character limit. Choose a visible-lines value that fits how much text users typically enter, so short notes do not sit in a cavernous box and long narratives are not crammed into a sliver. The setting is purely about editing comfort and page layout.
How to create a Long Text Area field
Create a Long Text Area field on any standard or custom object through Object Manager. The steps below follow the standard custom field wizard in Setup.
- Open Object Manager and pick the object
In Setup, go to Object Manager, select the object that needs the field, then open Fields and Relationships and click New.
- Choose the Text Area (Long) data type
On the data type step, select Text Area (Long). This is the option that maps to a Long Text Area field. Pick Text Area (Rich) instead only if you need formatting. Click Next.
- Set the label, length, and visible lines
Enter the field label and let the API name populate. Set Length up to 131,072 characters and set # Visible Lines to control the height of the input box on the page. Add help text if it aids users.
- Set field-level security and page layouts
Choose which profiles can see and edit the field, then select the page layouts where it should appear. Save to finish, and the field is live on the object.
The human-readable name shown on layouts and reports; the API name is derived from it.
The character cap for this field, from 256 up to 131,072; counts against the object's 1,638,400 character text budget.
How many rows of the text box render on the record page; affects display height only, not capacity.
- Do not declare 131,072 characters out of habit. The declared length counts toward the object's shared 1,638,400 character pool for all long and rich text fields.
- Users cannot filter list views by this field, and report filters only read its first 254 characters with the contains operator.
- Converting a Rich Text Area to a Long Text Area deletes any images and strips formatting the next time the record is saved.
Prefer this walkthrough as its own page? How to Long Text Area in Salesforce, step by step
Trust & references
Cross-checked against the following references.
- Custom Field TypesSalesforce
- Rich Text Area Field ConsiderationsSalesforce
Straight from the source - Salesforce's reference material on Long Text Area.
- Custom Field TypesSalesforce
- Editing Rich Text Area Fields in RecordsSalesforce
Hands-on resources to go deeper on Long Text Area.
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 the maximum number of characters a Long Text Area field can store?
Q2. By default, how does a Long Text Area field behave in global search?
Q3. Which field type is described as a Long Text Area with an HTML editor for formatting?
Discussion
Loading discussion…