What is the RFC-2822 date format?

It is the date format used in email headers, like Tue, 14 Nov 2023 22:13:20 +0000. It has an optional day-of-week, then day, abbreviated month, four-digit year, 24-hour time, and a numeric timezone offset.

How is RFC-2822 different from ISO-8601?

RFC-2822 uses English month and weekday abbreviations and a space-separated layout designed for email, while ISO-8601 is purely numeric and sortable. They describe the same instants in different text forms.

Does it accept named timezones like GMT or EST?

The numeric offset form (+0000, -0500) is the most reliable and is always supported. Common obsolete zone names such as GMT and UT are also handled, but numeric offsets are recommended.

Why does my header fail to parse?

Usually a typo in the month abbreviation, a missing offset, or non-standard spacing. RFC-2822 expects the three-letter English month (Jan, Feb, …) and a numeric or recognised timezone.

Is anything uploaded?

No. Parsing and formatting happen entirely in your browser. Nothing leaves your device.

RFC-2822 Date Converter

The RFC-2822 date format (updated by RFC-5322, and largely the same as the older RFC-822) is what you see in the Date: header of every email and in many HTTP-adjacent contexts: Tue, 14 Nov 2023 22:13:20 +0000. This converter decodes those headers into clean ISO-8601 and Unix timestamps, and builds correctly formatted RFC-2822 strings from a date — all locally in your browser.

How it works

JavaScript’s Date constructor natively understands the RFC-2822 format, so decoding is reliable:

const ms = Date.parse("Tue, 14 Nov 2023 22:13:20 +0000");
const date = new Date(ms);
date.toISOString(); // 2023-11-14T22:13:20.000Z

From there the tool derives epoch seconds (ms / 1000) and exposes the raw milliseconds. To build an RFC-2822 string, it assembles the parts in the required order using fixed English abbreviations:

Wkd, DD Mon YYYY hh:mm:ss ±hhmm

The day-of-week and month abbreviations come from fixed three-letter tables (Mon Tue Wed …, Jan Feb Mar …) so the output is always standards-compliant regardless of your system locale.

Example

The header Tue, 14 Nov 2023 22:13:20 +0000 converts to:

ISO-8601: 2023-11-14T22:13:20.000Z
Epoch seconds: 1700000000
Epoch milliseconds: 1700000000000

Tips and notes

Prefer numeric offsets (+0000, -0500) over named zones — named obsolete zones are ambiguous and discouraged by the spec.
The weekday is technically optional in RFC-2822, but including it is conventional and this tool always emits it.
The generated offset reflects UTC (+0000) so the output is unambiguous; convert to a local offset only if you specifically need one.