Received Header Timeline
Turn the Received chain of a pasted message into an ordered hop timeline with per-hop delays — entirely in your browser.
This tool handles input and primary processing in your browser and is designed not to send the input to QuickKit’s server.
Avoid live production secrets; use dummy or masked data where possible. Data handling details
Summary
Timeline
How it works
Paste a message's header block. Each server that handles a message prepends its own Received field, so the topmost one is the most recent; this tool reverses that order and shows the hops oldest first. For every hop it reads the from, by, with, id, for, and via clauses and the date after the final semicolon, then computes the delay between consecutive hops. Timestamps come from independent machines whose clocks may disagree, so a negative delay is reported as clock skew rather than hidden, and a date the browser cannot parse is reported as unparsed rather than guessed. A delay is shown only when the hop and the one directly before it both carry a usable timestamp; the interval beside an unparsed date stays unknown rather than being measured from an earlier hop, which would present several hops' elapsed time as one hop's delay. Total transit is the span between the oldest and the newest hop, so it needs those two hops' own timestamps and is otherwise not shown; an unknown hop in between stays inside that span, because the time did elapse even though no single hop can be charged with it. The hop order comes from the header order, not from the timestamps. Received fields can be forged by anything upstream of the first server you trust, so treat the lower hops as claims, not facts. No lookups are performed and no hop is judged suspicious. Everything runs locally; nothing is uploaded, stored, or written into the URL.