HAR File Viewer

A .har export is the browser's own record of what went over the wire. Open one here and line every request up against the Rails app that answered it.

All tools

Drop your .har export here

Chrome, Edge and Firefox all write the same HAR 1.2 shape, so an export from any of them opens here.

Everything runs in your browser. Nothing is uploaded.

What each column measures

Status is what the server answered, and a row marked fail never got an answer at all - in an export that usually means DNS, TLS, or a connection closed under the request. Size is the decoded size of the response body, so it will not match the bytes on the wire when the response was compressed, and a row that reads cached was served by the browser without asking anyone. Time is the whole round trip as the browser saw it: name lookup, connect, TLS, the wait for the first byte, then the download. The bar beside it shows when the request started relative to the first one in the file, so bars stepping down the page are serial loading and a block of them starting together is not.

Lining a row up with your Rails log

Every response from a Rails app carries an X-Request-Id, and that same value is the request id in log/production.log - open a row, find the header, grep the log, and you have the controller, the parameters and the SQL behind the number you were looking at. Turbo Drive navigations and anything from fetch arrive here as XHR rather than Document, which is the usual reason a page load looks missing. A POST that came back 422 with an unhelpful body is almost always the authenticity token, refused before your controller ran. And if every response body is empty, the export was saved without content.

Strip it before you attach it to a ticket

An export is a verbatim record, so it carries whatever the browser sent - session cookies, Authorization headers, CSRF tokens, and any signed link that arrived as a query string. Two of those are masked on this page until you press the reveal button: the cookie headers and the Authorization ones. Everything else is shown exactly as it was recorded - the full path and its query string included, and every remaining header with them, X-CSRF-Token among them. Nothing here rewrites the file either. Treat the .har itself as a live credential: open it, take the rows that matter, and paste those into the ticket instead of attaching the whole thing.

HAR files and Rails, answered

They measure different spans. The Rails log times the request from the moment the web server hands it to the router until the response is written. This number starts when the browser decided to make the request and ends when the last byte arrived, so it also holds the name lookup, the connection, TLS, whatever queueing the browser did, the download, and any proxy sitting in front of the app.

The bodies are only in the file if the export included them, and that is a separate choice at the moment you save. Export again and pick the variant that says it includes content. Responses the browser held as binary are kept out of the text either way and show as a size here instead.

Open the row and look in the request headers for X-CSRF-Token, and in the request body for authenticity_token. If neither is there, the form was submitted by something that did not carry one. If one is there and the request still failed, the session it belonged to had already been reset. Rails answers 422 before your controller action runs, so there is nothing in your own code to find.

Read the X-Request-Id response header off the row and grep the log for it. Rails stamps the same value on every line it writes for that request, so the header takes you straight to the parameters, the queries and the exception if there was one.

The browser answered that request out of its own cache, so nothing was fetched and there is no transferred size to report. It is worth noticing when you are trying to reproduce a first visit - a reload that keeps the cache does not exercise the same path as somebody arriving cold.

Start creating your next app now

Get BlueprintRead docs