LST File Documentation
Summary
A file with the .lst extension is almost always a plain-text List File: a list of items (file names, paths, part numbers, data values) or a program-generated listing, usually one entry per line. It has no fixed format and no magic number; the meaning is defined by the program that wrote it. Its MIME type is text/plain, so any text editor opens it. A minority of programs store a private binary index under .lst.
Technical details
| Feature | Value |
|---|---|
| Full name | List File (generic plain-text list / listing) |
| File extension | .lst |
| MIME type | text/plain |
| Format type | Usually plain text (one item per line); occasionally an app-private binary index |
| Developer | None — a generic convention reused by many unrelated programs |
| Magic number | None (no standard signature) |
| Character encoding | Application-defined (ASCII, UTF-8, or a legacy code page) |
| Line structure | Typically one list entry per line; may use # or ; comments |
| Delimited variant | Sometimes comma/tab-separated (CSV-like columns) |
| Standard / spec | None — not a defined format |
| Open standard | N/A (plain text is open; the layout is app-specific) |
| Category | Text Files |
| Safe to edit | Yes for text lists; back up first if a program reads it as input |
| Typical creators | Compilers/assemblers (listings), installers (manifests), games, scripts |
| Related extensions | .txt, .csv, .log, .m3u, .ini, .cfg |
What is a .lst file?
LST is short for “list”, and a .lst file is a generic, catch-all extension that many unrelated programs use to store a list of things, almost always as plain text. There is no single .lst standard, no governing body, and no magic number at the start of the file. What a given .lst contains depends entirely on the program that created it. Because most of them are just lines of ASCII or UTF-8 text, you can open any text .lst in Notepad, TextEdit, or an editor like Notepad++ and read it directly.
This is the honest picture: .lst is not a format in the sense that PNG or PDF is a format. It is a naming convention. The extension signals intent (“this file is a list”) rather than structure, so the only reliable way to know what a specific .lst holds is to look at which program produced it and to open it and read the contents.
What a .lst file typically contains
Across the many programs that use the extension, a handful of recurring patterns cover most real .lst files:
- A plain enumeration of items, one per line: file names, absolute or relative paths, part numbers, image references, or words. This is the commonest case and the simplest.
- A generated listing, such as an assembler or compiler listing file that shows source lines next to their memory addresses, opcodes, and generated bytes. Assemblers historically wrote these to
program.lst. - A manifest: a build tool, installer, or package system records the set of components, files, or inputs it should act on.
- An index or playlist that points a program at a group of data files to load or play in order.
- Delimited data: some
.lstfiles are really tables, with commas or tabs separating columns, which makes them CSV files in all but name.
Many text .lst files carry a first line or a block of comment lines (often prefixed with # or ;) that names the tool that wrote them or describes the columns. That header is usually the fastest clue to the file’s owner and purpose.
The binary .lst exception
A minority of applications reuse .lst for their own binary index or compiled-list data rather than text. If you open such a file and see mostly unprintable characters, control codes, and no readable words, it is one of these: an application-defined binary blob with no documented layout. A text editor cannot render it sensibly, and renaming it will not help, because the bytes are not text. The only program that can read it is the one that wrote it. There is no universal way to decode an arbitrary binary .lst, precisely because each program invents its own layout.
You can tell the two apart in seconds: open the file and look at the first screen. Readable lines mean it is a text list; a wall of gibberish means it is a program-specific binary file. On the command line, file name.lst on Linux or macOS will report “ASCII text” for the text case and “data” for the binary case.
Identifying the owning program
Because the extension is shared so widely, identification is a matter of context rather than signature. The folder the file lives in is the strongest hint: a .lst beside compiled objects and a source tree is a build or listing artefact; one inside a game’s data directory is that game’s asset or level list; one dropped by an installer is a manifest. Opening the file and reading its header comments or the shape of its lines usually confirms it. Do not assume a .lst from one ecosystem means the same thing as a .lst from another; the extension carries no shared meaning across programs.
Working with a text .lst as data
When a .lst is plain text, it is already the most portable thing it can be. If a tool insists on a .txt extension, renaming file.lst to file.txt changes nothing but the name; the bytes are identical. If the file is delimited (commas or tabs), a spreadsheet program can import it through its text-import wizard by choosing the delimiter, and a one-item-per-line list simply becomes a single column. Turning an arbitrary list into structured XML is not a generic operation: with no fixed schema, that requires a small script written for that specific file, which is why no general .lst-to-XML converter exists.
The main caution when editing is functional, not technical: if a program reads the .lst as input (a build manifest, a batch list, a set of paths it will process), changing the lines changes what that program does. Keep a copy of the original before you edit an input list.
References
- Notepad++ — free source-code and text editor
- Visual Studio Code — text and code editor
- GNU nano — terminal text editor
Feedback
Was this page helpful?
Glad to hear it! Please tell us how we can improve.
Sorry to hear that. Please tell us how we can improve.