Guide
Analysing Apache and Nginx access logs in the browser
Web server access logs record every request a site receives: who asked, for what, when, and how the server answered. They answer questions analytics cannot, such as which pages return errors, how much traffic is bots and what scanners are probing, but a raw log is thousands of dense lines. This analyzer reads an Apache or Nginx access log and turns it into summaries and top lists, entirely in your browser.
The combined log format
Both Apache and Nginx write the Combined Log Format by default. Each line holds the client IP, two rarely used identity fields, the time in brackets with its UTC offset, the request line in quotes (method, path and protocol), the status code, the number of bytes sent, and in quotes the referrer and the user agent. The older Common Log Format stops after the bytes; the analyzer reads both.
Parsing and times
Every line is matched against that layout. Lines that do not fit, such as error-log entries or custom formats, are counted as skipped and reported, so you know whether the whole file was understood. Times are converted to UTC using the offset on each line, which keeps logs from servers in different time zones comparable and makes the hourly chart consistent.
The summaries
The top row counts requests, unique IP addresses, bytes sent, 404 Not Found responses, server errors and bot requests, and gives the time span the log covers. Below, top lists show the most requested pages (with query strings removed so variants group together), status codes, the paths behind 404s and 5xx errors, the busiest IP addresses, referrers, user agents and requests per hour.
Bots and people
A large share of traffic on most sites comes from crawlers, monitoring services and scripts. Requests whose user agent contains a crawler name or an HTTP library, such as Googlebot, Bingbot, GPTBot, curl or python-requests, are counted as bots, and the “Hide bots and scripts” toggle removes them from every list. User agents can be faked, so treat this as a good filter rather than a verdict.
A worked example
The Sample is a 60-line log from five IP addresses. It contains 34 responses with status 200, six 404s, all for /wp-login.php, and seven 500 errors from /api/search. Twenty-six requests come from bots: the Googlebot visits and a python-requests scanner probing the WordPress login page. With bots hidden, 34 requests remain. Those numbers point to two concrete jobs: fix the failing search endpoint and consider blocking the scanner.
Privacy
Access logs contain visitors’ IP addresses and sometimes personal data in URLs, which count as personal data under GDPR. This page reads the file with the browser’s File API and keeps everything in the tab; nothing is uploaded. If you need to share findings, share the summaries or redact the log first.
What it cannot read
Compressed rotated logs (access.log.2.gz) need to be unzipped first. Custom log_format or LogFormat definitions that change the field order, JSON logs and logs from CDNs or load balancers have different layouts and are skipped. Very large logs work but are held in memory, so split multi-gigabyte files.
Related tools
- HAR Analyzer shows the same requests from the browser’s side.
- User-Agent Parser decodes a single agent string in detail.
- Redact Log Secrets removes IPs and emails before sharing a log.
- HTTP Status Codes explains every status in the report.
Checked against the current version of the Access Log Analyzer on .