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.

When you need this converter

The most common use cases are:

• Parsing email metadata: extracting a machine-readable timestamp from an email Date: header for logging, sorting, or deduplication
• Debugging SMTP flows: verifying that a Date header in a raw email message or mail log is correctly formed
• Generating compliant headers: building a Date header to inject into a constructed email or an SMTP test payload
• Timestamp archaeology: converting an old email archive timestamp to ISO-8601 for database ingestion

The RFC-2822 format is not used much outside of email, but when you encounter it in an email context you often need an immediate conversion to something sortable like ISO-8601 or a Unix timestamp.

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.

RFC-2822 vs RFC-5322 vs RFC-822

These three standards all describe the same fundamental date format for email headers. RFC-822 was the original (1982); RFC-2822 superseded it in 2001 with clarifications; RFC-5322 updated it again in 2008. For the purposes of the date header specifically, the differences are minor. The main practical change across the versions was the deprecation of some obsolete two-digit year formats and ambiguous timezone names. If you are writing new code, follow RFC-5322 — in practice the format is so stable that the version rarely matters.

Example

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

Tips and notes

• Prefer numeric offsets (+0000, -0500) over named zones like GMT or EST — named obsolete zones are ambiguous across implementations and discouraged by the spec.
• The weekday is technically optional in RFC-2822, but including it is conventional and this tool always emits it when generating a string.
• The generated offset reflects UTC (+0000) for unambiguity; convert to a local offset only if you specifically need one.
• Common parse failure causes: misspelled month abbreviation (only Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec are valid), missing timezone offset, or non-standard spacing around the comma.