# How Pliro stores text files

[Syntax and values](README.md)

A source file stores your program's letters and symbols as bytes. A **text encoding** is the agreement for turning those bytes back into text. Pliro uses **[UTF-8](../concepts/utf-8.md)**. You can type ordinary text and emoji; the editor handles the conversion when saving.

## What is UTF-8?

UTF-8 uses one to four bytes for a [Unicode](../concepts/unicode.md) code point. `A` takes one byte and `🐢` takes four. A code point is a numbered element of text; several can sometimes make one visible character. Pliro's `length` counts code points, not file bytes. The [UTF-8 article](../concepts/utf-8.md) has a table and a program to try.

## New lines and positions

Pliro accepts LF, CRLF, and legacy CR line endings. These are different stored control characters for the boundary between lines. CRLF counts as one new line. [Line endings](../concepts/line-endings.md) explains the abbreviations.

Line and column numbers shown to people start at one. Columns count [Unicode code points](../concepts/code-points.md). Invalid UTF-8 produces a lexical error: Pliro cannot read part of the source as valid text.

Save source as **UTF-8 without BOM**. A **BOM** is an extra, invisible label that some editors add before your text. It is not a line of Pliro code. Pliro currently rejects this label. Choose the editor's “UTF-8 without BOM” saving option; [the BOM explanation](../concepts/utf-8.md#what-is-a-bom) shows the steps. A non-empty file does not need a final newline, although the formatter adds one.

[Unicode](../concepts/unicode.md) · [Code points](../concepts/code-points.md) · [Source-language directive](locale.md)