All free tools Parsed in your browser

Nginx and Apache Log Analyzer

Paste or load an access log to see traffic totals, status codes, top visitors, error hotspots, bot activity, and bandwidth by hour.

Analyse an access log

access.log
One request per line, in Common Log Format or NCSA Combined format. A leading virtual-host field and an nginx $http_x_forwarded_for suffix are both tolerated.
The file is read locally with your browser's FileReader and is never uploaded. Maximum file size 12 MB; at most 300,000 lines are parsed and the rest is ignored.
Auto-detect reads the referrer and user-agent fields when they are present. Force a format if detection picks the wrong one.
Used only to drop self-referrals from the referrer table. Leave it blank to keep every referrer.

Your log never leaves this device. Pasted lines and any file you select are parsed in your browser only. Nothing is uploaded to VPSLake, stored, or sent to any other service, so visitor IP addresses and request paths stay with you.

Analyse a log in four steps

Access logs normally live in /var/log/nginx/access.log or /var/log/apache2/access.log on Debian and Ubuntu, and in /var/log/httpd/access_log on RHEL, AlmaLinux and Rocky Linux.

  1. 1

    Collect the lines you want to review

    Copy a section with tail -n 20000 /var/log/nginx/access.log, or download the file and select it with the file picker. Reading the file needs no root access if your user is in the adm group.

  2. 2

    Paste the lines or pick the file

    Paste into the text area, or choose a plain-text log of up to 12 MB. Add your hostname if you want self-referrals removed from the referrer table.

  3. 3

    Analyse the log

    Leave the format on auto-detect unless the report says lines failed to parse. The tool then reports totals, status codes, top addresses, error hotspots, bandwidth and bot traffic.

  4. 4

    Act on the result

    Start with the 5xx table, then the 404 table. Copy or download the plain-text report to attach to a support ticket, a change record, or a note for the rest of your team.

Which log formats are read

Both nginx and Apache write the same two classic shapes. The NCSA Combined format adds a referrer and a user agent to the end of the Common Log Format line, which is why nginx combined and Apache combined produce identical output.

A Combined line looks like this:

203.0.113.10 - - [28/Aug/2026:04:11:02 +0000] "GET /pricing HTTP/1.1" 200 5312 "https://example.com/" "Mozilla/5.0"

The parser also accepts a leading virtual-host field, as written by Apache's %v or a shared-hosting combined-vhost log, and it accepts the extra quoted field that many nginx configurations append for $http_x_forwarded_for. Lines that match neither shape are counted as unparsable and reported rather than silently dropped.

What the report contains

The report is a snapshot of the lines you supplied, not of your whole site. Everything is derived from the log text alone, with no lookups of any kind.

  • Request totals, unique addresses, bytes served and average response size
  • Status-code table with 2xx, 3xx, 4xx and 5xx class totals
  • Top addresses and top paths, with bytes and error counts
  • Separate 5xx and 404 tables, which are the two most actionable views
  • Bandwidth per hour and a human against bot split
  • Observations that flag error spikes, single-address floods and scanner probes

Bot detection reads the user-agent string, which any client can set to anything. Treat it as a strong hint rather than proof of identity.

Confirm an address before you block it

A high request count is not proof of abuse. Corporate networks, mobile carriers, university campuses and CDN or reverse-proxy nodes all place many genuine visitors behind one address, and a request count taken from a short window can be misleading. If your site sits behind a proxy or CDN, the first field may be the proxy rather than the visitor, so check X-Forwarded-For handling before drawing conclusions. Verify the pattern over a longer period and review the paths involved before adding a firewall rule, and never block an address that is also completing normal requests.

Log Analyzer FAQ

The Common Log Format, the NCSA Combined format used by nginx combined and Apache combined, and Apache common. An optional leading virtual-host field and a trailing quoted $http_x_forwarded_for field are tolerated. Custom log_format directives that reorder or rename fields, JSON access logs, and error logs are not supported, and their lines are counted as unparsable.
A rotated plain-text file such as access.log.1 loads normally. A .gz file must be decompressed first, because the tool reads plain text and does not unpack archives. Use gunzip -c access.log.2.gz > /tmp/access-old.log, or combine several days with zcat access.log.*.gz > /tmp/access-all.log, then load the plain file.
A selected file may be up to 12 MB, and at most 300,000 lines are parsed from either the text area or the file. If a log is longer, the first 300,000 lines are analysed and the status line says how many were skipped, so the report is never silently partial. For a busy site, take a slice of the period you care about with tail, head or grep before loading it.
No. Parsing, counting and report building all run in your browser with JavaScript. The file you select is read locally through FileReader. Nothing is uploaded to VPSLake, saved in your browser, or sent to a third party, which matters because an access log contains visitor IP addresses and the pages they viewed.
Those tools apply their own rules. GoAccess distinguishes visitors from hits and can exclude static assets or crawlers by configuration, and AWStats de-duplicates sessions and keeps a persistent history across rotations. This tool counts every parsed request line exactly once with no session logic and no exclusions, so totals will differ. It also only sees the lines you supply, while a long-running collector sees every rotation.
It is a good indicator, not proof. The tool matches known crawler names such as Googlebot, Bingbot, AhrefsBot, GPTBot and ClaudeBot, common command-line clients such as curl and python-requests, and a general fallback for any agent containing bot, crawler or spider. A user agent is set by the client and can be copied or forged, so verifying a crawler properly needs a reverse DNS check on the source address, which this tool does not perform.
It does no geolocation, no reverse DNS, no threat-intelligence lookup and no session or unique-visitor modelling, because every one of those needs a network request that would send your visitors' addresses somewhere. It does not read error logs, it does not follow a log file live, and it does not write firewall rules for you. The report is a reading of the text you supplied, meant to point you at the next thing to investigate.
The most common causes are a custom log_format, a JSON access log, or an error log pasted by mistake. Check the first line of your file: it should begin with an address, then two placeholder fields, then a bracketed timestamp. If your format simply reorders standard fields, exporting a short sample in combined format is the quickest way to get a usable report.