LOG File Documentation

---

Technical details

Feature	Value
Full name	Log file
File extension	.log
MIME type	text/plain
Format type	Plain-text, line-oriented event log
Developer	N/A — generic convention across OSes and apps
Encoding	Usually UTF-8 or ASCII
Open standard	Yes — it is just text
Magic number	None — no header or signature
Line structure	App-defined; often timestamp + level + message
Common severity tags	DEBUG, INFO, WARN, ERROR, FATAL
Timestamp style	Often ISO 8601 (2026-06-11 10:42:01) or epoch
Written by	OSes, servers, installers, drivers, applications
Growth handling	Rotation (app.log.1, app.2026-06-10.log), often gzipped
Safe to delete?	Usually yes for old/rotated logs; active log may be locked
Binary exception	A few apps write binary/proprietary .log (games, DB, ETL traces)
Best openers (large)	Notepad++, VS Code, klogg/glogg, less
Related extensions	.txt, .csv, .etl, .evtx, .out, .trace
Category	Text

What is a LOG file?

A .log file is a generic, plain-text journal of events. Operating systems, servers, installers, drivers and ordinary applications append lines to .log files to record what they did and when: startup and shutdown, user actions, network requests, and above all warnings and errors. There is no owner, no version and no specification — "log file" is a convention as old as software logging itself, and the extension only signals intent (this text is a record of events), not a fixed structure. Each program decides its own line format, so two .log files from different apps can look nothing alike.

Because it is just text, a .log can be opened and read in any text editor; nothing needs to interpret it. That also means there is no header or magic number to document. What is worth knowing is the shape most logs share (a line per event, usually stamped with a time and a severity), how logs are rotated as they grow, the handful of programs that write binary logs instead, and whether a given .log is safe to delete. Those are the sections below.

The shape of a log line

Almost all text logs are line-oriented: one event per line, appended in time order, so the newest events are at the bottom of the file. While the exact format is app-defined, a very common convention puts a timestamp first, then a severity level, then the source and the message.

2026-06-11 10:42:01,317  INFO  [main]  Service started on port 8080
2026-06-11 10:42:03,004  WARN  [pool-2]  Retry 1/3 connecting to db
2026-06-11 10:42:05,981  ERROR [pool-2]  Connection refused: db:5432
    at net.Conn.open(Conn.java:212)
    at app.Repo.query(Repo.java:88)

The timestamp lets you line up an event with when a problem happened; it is often ISO 8601 (2026-06-11 10:42:01) or a Unix epoch number. The severity level — typically DEBUG, INFO, WARN, ERROR or FATAL — is the field you search for, because errors and fatals are where failures surface. A source field names the component or thread that emitted the line, and the message is the human-readable text, sometimes trailed by a multi-line stack trace as in the ERROR above. Reading a log to diagnose a crash is mostly this: find the first ERROR or FATAL near the failure time and read the lines just before it, since the cause usually precedes the symptom.

Rotation and how logs grow

Active logs keep growing as a program runs, so software "rotates" them to stop a single file from becoming unmanageable. Rotation renames the current log and starts a fresh one, producing a series such as app.log, app.log.1, app.log.2, or date-stamped names like app.2026-06-10.log. Older rotated files are frequently compressed to gzip (access.log.2.gz) to save space, which is why you often find .log.gz files in a server's log directory. This matters when you are hunting a past event: the line you want may be in a rotated or compressed older file rather than the live .log.

Opening a huge log without freezing

Logs can reach hundreds of megabytes, and lightweight editors like Notepad choke on them. For large files use an editor built to stream them: Notepad++ or VS Code on Windows, or a dedicated log viewer such as klogg or glogg. On Linux and macOS, less bigfile.log opens instantly no matter the size — press G to jump to the end (the most recent events) and type /error to search forward. The general technique for any log is the same: jump to the relevant timestamp, then search for error, fail, exception or fatal.

When a LOG file isn't text

A minority of programs write .log files that are not plain text at all. Some games, database transaction logs and Windows ETL (Event Tracing for Windows) traces store their logs in a binary or proprietary layout that looks like garbage in a text editor. These need the vendor's own tooling — a database's log reader, or a trace viewer for ETL — rather than Notepad. If a .log opens as unreadable characters, that is the sign you have one of these, not a corrupt text file.

Is a LOG file safe, and can I delete it?

A plain-text .log cannot execute and is safe to open in a text editor. Two real cautions apply. First, logs often contain sensitive data — usernames, IP addresses, file paths, tokens, sometimes even passwords — so scrub them before posting to a public forum or attaching to a ticket. Second, be wary of a file that pretends to be a log but has a double extension such as report.log.exe: that is a program, not a log. As for deleting, old rotated logs are generally safe to remove since they are just history; the currently active log may be locked by the running program, and you should not delete a log that support has asked you to send.

Frequently asked questions

What program opens a LOG file?

Any text editor: Notepad or Notepad++ on Windows, TextEdit on macOS, gedit or less on Linux. There is no special "log viewer" needed for standard text logs; pick Notepad++ or VS Code for large files so they don't slow down.

Can I delete LOG files?

Usually yes — they are a history of past events. Old, rotated logs are safe to remove; an app's current log may be locked while the program runs. Don't delete a log that support has asked you to send.

Why is my LOG file full of strange characters?

A few programs write binary or proprietary .log files (some games, database transaction logs, Windows ETL traces). Those are not plain text and need the vendor's own viewer rather than a text editor.

References

• Microsoft — Windows event tracing and log tools
• Apple — Console User Guide (macOS system logs)
• klogg — fast viewer for very large log files

Feedback

Was this page helpful?

Yes No

Glad to hear it! Please tell us how we can improve.

Sorry to hear that. Please tell us how we can improve.