Zero Signup ToolsFree browser tools

Developer Tools

HTTP Date Formatter

Build and parse HTTP-date strings in IMF-fixdate, RFC 850, and ANSI C asctime formats for Date, Expires, Last-Modified, and Set-Cookie headers.

Source timestamp

Pick a source. The same instant is emitted in all three HTTP-date formats, with ready-to-paste header lines.

Using the current browser clock. Click to snap the timestamp to this exact moment.

IMF-fixdate (RFC 7231)

The format new HTTP messages must use.

Mon, 08 Jun 2026 12:18:21 GMT

RFC 850 (obsolete)

Accepted by parsers for backward compatibility.

Monday, 08-Jun-26 12:18:21 GMT

ANSI C asctime

Legacy form. No comma after the weekday.

Mon Jun 8 12:18:21 2026

Header lines ready to paste

Date: Mon, 08 Jun 2026 12:18:21 GMT

Expires: Mon, 08 Jun 2026 12:18:21 GMT

Last-Modified: Mon, 08 Jun 2026 12:18:21 GMT

If-Modified-Since: Mon, 08 Jun 2026 12:18:21 GMT

If-Unmodified-Since: Mon, 08 Jun 2026 12:18:21 GMT

Retry-After: Mon, 08 Jun 2026 12:18:21 GMT

Set-Cookie: session=abc123; Path=/; Expires=Mon, 08 Jun 2026 12:18:21 GMT

Where HTTP-date strings appear, and which format to send

Headers that use HTTP-date

  • Date: when the response was generated by the origin server.
  • Expires: when a cached response is considered stale (HTTP/1.0 caches, RFC 9111).
  • Last-Modified: when the representation was last changed.
  • If-Modified-Since and If-Unmodified-Since: conditional GET / PUT.
  • Retry-After: when the client should retry (also accepts seconds).
  • Set-Cookie with the Expires= attribute (RFC 6265).

Sender and parser rules

  • New HTTP messages MUST send IMF-fixdate (RFC 7231 7.1.1.1).
  • Parsers MUST accept all three formats listed in the input examples.
  • The time zone MUST be the literal string GMT, not UTC, not a numeric offset.
  • Day and time components are zero-padded to two digits, except the asctime form which space-pads the day.
  • Fractional seconds and time zones other than GMT are not allowed.
  • The weekday name in the input is advisory only; parsers must not reject a date based on a mismatched weekday.

How to use

  1. Choose Build HTTP date to convert a timestamp into header-ready strings, or Parse HTTP date to inspect an existing one.
  2. In Build mode, pick a source (current time, a calendar date and time, a Unix timestamp, or an ISO 8601 string).
  3. Copy the IMF-fixdate output for new headers, or grab a ready-to-paste line for Date, Expires, Last-Modified, Retry-After, or Set-Cookie Expires=.
  4. In Parse mode, paste any HTTP-date string and see the detected format, the canonical IMF-fixdate, ISO 8601, Unix seconds and milliseconds, plus a diff against now.
  5. Watch the warnings panel for common sender mistakes: numeric offsets, the UTC token, missing leading zeros, weekday/date mismatches, and RFC 850 two-digit years.

About this tool

HTTP Date Formatter builds and parses HTTP-date strings as defined by RFC 7231 section 7.1.1.1, the timestamp format used in the Date, Expires, Last-Modified, If-Modified-Since, If-Unmodified-Since, Retry-After (date form), and Set-Cookie Expires= header values. The spec recognizes three formats: IMF-fixdate (the modern form, e.g. Sun, 06 Nov 1994 08:49:37 GMT) which every new HTTP message MUST send; the obsolete RFC 850 form with a two-digit year; and the legacy ANSI C asctime form. Parsers MUST accept all three for backward compatibility. In Build mode, pick the source for the instant (the current browser clock, a manual date and time, a Unix timestamp in seconds, a Unix timestamp in milliseconds, or an ISO 8601 string) and the tool emits all three formats side by side with copy buttons, plus ready-to-paste header lines for Date, Expires, Last-Modified, If-Modified-Since, If-Unmodified-Since, Retry-After, and a complete Set-Cookie example with the Expires= attribute. In Parse mode, paste any HTTP-date string and the tool detects which of the three formats it is in, reports the canonical IMF-fixdate equivalent, ISO 8601 in UTC, Unix seconds, Unix milliseconds, and a human-readable diff against the current clock. It also flags the most common non-compliance issues senders produce: a numeric zone offset like +0000 instead of GMT, the literal UTC token instead of GMT, single-digit day or hour fields, fractional seconds, a missing comma after the day name, weekday names that disagree with the calendar date, and the RFC 6265 two-digit year window used to disambiguate obsolete dates. Everything runs locally in your browser, so the timestamps you build or parse are never uploaded.

Free to use. Works in your browser. No signup, no login.

Related tools

You may also like

All tools
All toolsDeveloper Tools