> For the complete documentation index, see [llms.txt](https://guardian.hedera.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://guardian.hedera.com/docs/develop/guardian/workspace/schemas/schema-fields-reference/rich-text-fields.md). # Rich Text Fields A Rich Text field is a schema string field that accepts formatted text instead of one flat paragraph. The author of a schema picks the **Rich Text** type, and the field then offers a small editor - headings, bold, italic, bulleted and nested lists, numbered lists, hyperlinks, tables and images - both to the person filling in a form and to the schema author writing the field's preset values. The value is stored as **Markdown** in an ordinary string field, so the formatting travels with the document wherever it goes and the document itself carries readable text rather than markup. ### The problem it solves Every other text field in a schema is plain text. Instructions, notes and guidance all arrive as one unbroken block: there is no way to mark a sentence as important, to break a procedure into a numbered list, or to point at an external page. Long fields become hard to scan, and readers miss the part that mattered. ### How it works Picking **Rich Text** as a field's type gives it a small toolbar and a writing area, in the form and wherever the schema author sets a preset value. The toolbar covers undo and redo, bold and italic, bulleted and numbered lists with their indent controls, three heading levels, links, tables and images. What you type is saved as Markdown: in its raw form a heading looks like `# Heading` and bold text looks like `**bold**`. The editor hides that while you write - Markdown turns into formatting the moment a value is opened, and formatting turns back into Markdown as you type. Lists can be nested, and a table is stored as a Markdown pipe table. A table always keeps one header row, so the header and the last remaining column cannot be removed; cell alignment, colours, borders and merged cells are not stored. An image is not embedded in the value: the picture is uploaded to IPFS and the value keeps a reference to it. PNG, JPEG and WebP files are accepted, up to 512 KB after the browser shrinks them. The field's preset values - **Default**, **Suggested** and **Test value** - open the same editor in its own dialog, reached from a small preview card in the field's settings. The field's type survives an Excel export and import. The Indexer shows the same formatting as Guardian's document view, tables and images included, though it has no editor of its own. Where the full value would not fit - a suggestion under the field, or a documents-grid column set to **Rich Text** - Guardian shows the text and reveals the formatted version on hover. ### Key distinctions * **The field type decides the rendering, not the content.** A plain String field containing `#` or `**` stays plain text and displays exactly as typed. Only a field set to Rich Text renders as formatted output. * **Existing fields are untouched.** Every other field type behaves exactly as it did before this feature existed, in the form and in the viewer, including in documents created earlier. ### Related * Task: [Configure Rich Text Fields](/docs/develop/guardian/workspace/schemas/schema-fields-reference/rich-text-fields/configure-rich-text-fields.md) --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://guardian.hedera.com/docs/develop/guardian/workspace/schemas/schema-fields-reference/rich-text-fields.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.