Detection happens on open
A byte-order mark settles it outright. Without one the file is decoded by trying the plausible encodings, so a UTF-8 file with no BOM is not mistaken for Latin-1 because of one high byte.
Text encoding
Eleven encodings,
chosen and preserved rather than guessed.
An editor that opens everything as UTF-8 is fine until the day it saves a Windows-1252 file as UTF-8 and the accented characters in someone else’s toolchain turn into mojibake. Linelark treats the encoding as a property of the file, not a preference of the app.
Studio 1.4.0 · macOS 14+6.5 MB download
The mechanism
Detect, preserve, reinterpret, convert.
Those are four different operations and most editors offer two. The distinction that matters is between reading the same bytes a different way and rewriting the bytes into a different encoding.
The encoding is carried with the document
It is not a global setting. Two tabs can hold two encodings, and each saves in its own.
Reinterpret rereads, convert rewrites
Reinterpreting takes the bytes on disk and decodes them again with an encoding you choose — the fix when a file opened as the wrong thing. Converting changes what will be written. Only one of them alters the file.
Line endings are their own axis
LF, CRLF and CR are tracked separately from the encoding and shown separately, because a file’s endings and its character set have nothing to do with each other.
A BOM is a choice, not an accident
UTF-8 is offered with and without a byte-order mark as two separate entries, because for a shell script the difference is whether it runs.
Folder replace inherits all of this
Replace in Files decodes each file with its own encoding and writes it back the same way, so a bulk edit never becomes a bulk conversion.
Specifics
Exactly what is in the Encoding menu.
Eleven entries, listed here in full rather than described as “all the common encodings”.
| Encoding | What it is for |
|---|---|
| UTF-8 | The default for anything new. |
| UTF-8 with BOM | When a Windows tool insists on the mark. Written as EF BB BF. |
| UTF-16 LE BOM | Windows APIs and older exports. Written as FF FE. |
| UTF-16 BE BOM | Big-endian UTF-16. Written as FE FF. |
| ISO 8859-1 (Latin-1) | Western European legacy text and older HTTP bodies. |
| Windows-1252 | The Windows superset of Latin-1 — the usual source of smart quotes arriving as junk. |
| Windows-1251 | Cyrillic on Windows. |
| Mac OS Roman | Classic Mac text files, still found in long-lived archives. |
| Japanese (Shift-JIS) | The dominant legacy Japanese encoding. |
| Japanese (EUC-JP) | Unix-side Japanese text. |
| US-ASCII | When you want the save to fail rather than silently widen. |
Read from the Linelark Studio 1.4.0 source, not from its documentation. Where the two disagree, this is the one that ships.
Before you rely on it
What this does not cover.
Eleven encodings is a deliberate list, not an exhaustive one. If yours is not here, this is the wrong editor for that file.
- No GB18030, Big5, KOI8 or ISO 8859 beyond Latin-1Chinese and Korean legacy encodings are not in the menu. A file in one of them will not open correctly and cannot be converted here.
- Detection is not infallibleShort files with no BOM carry very little evidence. A 40-byte Windows-1252 file that is also valid UTF-8 will open as UTF-8, and reinterpreting is the fix.
- No per-folder or per-language defaultThe encoding is chosen per document. There is no rule engine that opens everything under one directory as Shift-JIS.
- Vertical text and CJK typesetting are absentReading and writing Japanese encodings is not the same as typesetting Japanese. CotEditor supports vertical writing mode; Linelark does not.
Free, and staying free
Open it on
your own files.
Apple-notarized, macOS 14 and newer, Intel and Apple silicon.
Choose a release 6.5 MB · versioned checksums on the download page