Text
A Text field is a Salesforce field data type that stores a single line of alphanumeric content up to 255 characters.
Definition
A Text field is a Salesforce field data type that stores a single line of alphanumeric content up to 255 characters. It holds short strings such as names, codes, reference numbers, and brief labels, and it is the field type admins reach for first when a value is plain, short, and free-form. In the API and in Apex this type is represented as a string, and it is the data type SOQL compares against by default in WHERE-clause equality checks.
A Text field can be configured to enforce unique values, act as an External ID for upsert matching, and treat values as case sensitive. For content that needs more room or multiple lines, Salesforce offers Text Area (255 characters, multi-line), Long Text Area (up to 131,072 characters), and Rich Text Area (HTML-formatted). Choosing Text means choosing a deliberate cap and a single line.
How the Text field behaves inside Salesforce
What "Text" actually stores and its 255 limit
A Text field accepts any alphanumeric characters, punctuation, and spaces on a single line, with a hard ceiling of 255 characters. When you create the field you set a length from 1 to 255, and the platform rejects saves that exceed it. The length you pick is not just a guardrail. It documents intent. A field capped at 10 tells the next admin that a short code lives here, while one left at 255 signals open-ended notes. Text is the type behind most standard short fields too, including Account Name and many reference numbers. Because the value is plain text, it sorts alphabetically and matches literally in filters. There is no formatting, no line breaks, and no markup. If a user pastes a paragraph with returns, the line breaks are stripped or the save fails depending on context. For anything longer than a single tidy line, Text is the wrong choice, and that is exactly when Text Area, Long Text Area, or Rich Text Area earn their place. Treat 255 as the line you do not cross with this type.
Unique, case sensitivity, and the default value
Three checkboxes change how a Text field behaves. Marking it Unique stops two records from sharing the same value, which is how you keep external keys and account codes from colliding. By default Unique is case insensitive, so ABC123 and abc123 count as the same. Tick the case-sensitive option and they become two distinct values. That setting matters most when your source system treats case as meaningful, such as a coding scheme where uppercase and lowercase carry different meaning. Be careful, because flipping case sensitivity after data exists can surface duplicates that were previously hidden. You can also set a default value using a formula, so new records arrive pre-filled with a computed string. A common pattern is seeding a status code or a region prefix. Defaults only apply at create time and do not overwrite values a user types. Together these options turn a plain string field into something closer to a lightweight key, without needing Auto Number or a formula field. Plan the combination before you load data.
Text as an External ID for upsert
Marking a Text field as External ID is one of the most useful things you can do with this type. An External ID flags the field as a record identifier that originates outside Salesforce, such as a primary key from an ERP or a legacy CRM. Once flagged, the field becomes indexed and searchable, and Data Loader or the API can match on it during an upsert. Upsert means insert if no match exists and update if one does, keyed on that External ID rather than the Salesforce record Id. This is the backbone of most integrations, because the external system rarely knows the 18-character Salesforce Id. You can mark a Text, Number, or Email field as External ID, and a single object can have several. Pairing External ID with Unique is common, since a key that repeats defeats the purpose. The field still counts as ordinary Text in every other way, so it shows on the page, exports normally, and obeys field-level security. When you plan a sync, the External ID Text field is usually the first field you design.
Text versus the longer text field types
Salesforce gives you four text-shaped types, and the gap between them is size and structure. Text is one line, up to 255 characters. Text Area is also capped at 255 but allows multiple lines, which suits short addresses or two-line notes. Long Text Area jumps to a configurable ceiling, defaulting to 32,768 characters and going up to 131,072, and it is the home for descriptions, logs, and pasted blocks. Rich Text Area shares that 131,072 limit but stores HTML, so it keeps bold text, links, lists, and inline images. One detail trips people up. For the long and rich types, the limit is enforced at the character level in the UI but at the byte level through the API, so multibyte characters and HTML entities consume more of the budget than they appear to. An object can hold up to 1,638,400 characters across all its Long Text Area and Rich Text Area fields combined. Pick Text when the value is genuinely short and single-line, and step up only when the content demands it.
Text fields in SOQL, Apex, and reports
In code and queries a Text field is a string. SOQL compares it with equality and the LIKE operator, so WHERE Name = $body$Acme$body$ and WHERE Code LIKE $body$AB%$body$ both work, and string matching on a non-unique Text field is generally case insensitive in SOQL. Apex reads and writes the value as a String, so you assign it directly, concatenate it, and run String methods like trim or toUpperCase before saving. Standard indexing covers fields marked Unique or External ID, which makes filters on those fields fast even on large tables. Plain Text fields without those flags are not indexed by default, so a LIKE filter with a leading wildcard can be slow at scale. In reports, Text fields group and filter cleanly but cannot be summarized with sums or averages, because they are not numeric. If you find yourself doing math on a Text field, that is a signal the data should have been a Number or a picklist. Keeping the type honest keeps your reports and automation predictable.
When not to use a plain Text field
Text is flexible, and that flexibility is also its weakness. A free-form Text field invites typos, inconsistent casing, and a dozen spellings of the same value, which wrecks grouping and reporting later. If the set of valid values is known and finite, a Picklist is almost always the better call, because it constrains input and keeps reports clean. If the value is a true number you will calculate with, use Number or Currency so math and aggregation work. If you need a system-generated sequence, Auto Number gives you a unique running identifier without manual entry. Phone, Email, and URL types add light formatting and validation that a generic Text field does not. Reserve Text for genuinely open-ended short strings where no stricter type fits, such as a building name or a one-off reference. You can also pair a Text field with a validation rule to enforce a pattern, for example a postal code shape, when a picklist is too rigid but raw text is too loose. The right type chosen up front saves a painful data cleanup down the road.
Create a custom Text field
Create a custom Text field on any standard or custom object through Object Manager. The flow is the same in Lightning Experience whether the object is Account, a custom object, or anything in between.
- Open Object Manager
From Setup, go to Object Manager and select the object you want to add the field to. Click the Fields and Relationships section, then click New.
- Choose the Text data type
On the data type screen, select Text, then click Next. Pick Text, not Text Area, when you want a single line capped at 255 characters.
- Set label, length, and options
Enter a field label, which auto-fills the API name, and set the Length from 1 to 255. Optionally mark the field as Unique, External ID, or case sensitive, and add a default value if you need one.
- Set security and layouts
Choose which profiles can see and edit the field through field-level security, then select the page layouts where it should appear. Click Save to create the field.
The human-readable name shown on layouts and reports. It auto-generates the API name, which you can adjust before saving.
The maximum number of characters, from 1 to 255. Setting it deliberately documents the expected content rather than defaulting everything to 255.
The unique developer name used in code, SOQL, and integrations. It must be unique on the object and cannot start with a number.
- You cannot exceed 255 characters with the Text type. If you need more, choose Text Area, Long Text Area, or Rich Text Area instead.
- Marking an existing field Unique fails if duplicate values already exist, so clean the data first.
- Switching a populated Text field to case sensitive can expose duplicates that were previously treated as identical.
- Plain Text fields without Unique or External ID are not indexed, so filters with a leading wildcard can be slow on large objects.
Trust & references
Cross-checked against the following references.
- Custom Field TypesSalesforce
- Field Types (Object Reference for the Salesforce Platform)Salesforce
Straight from the source - Salesforce's reference material on Text.
- Custom Field TypesSalesforce
- Change the Data Type of a Custom FieldSalesforce
Hands-on resources to go deeper on Text.
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 Text field type?
Q2. What's the max length?
Q3. When use Text vs Text Area?
Discussion
Loading discussion…