Developer & system utilities
RFC 3339 / 2822 formatter
Emit the exact timestamp string a system expects. Take the current moment or any date and get RFC 3339, RFC 2822, ISO 8601, an HTTP Date header, and Unix time — ready to copy.
Enter a valid date and time.
RFC 3339 is the strict internet-timestamp profile of ISO 8601. RFC 2822/5322 is the email and HTTP-adjacent format; the HTTP Date header always uses GMT.
How to use the rfc 3339 / 2822 formatter
Pick the format you need
RFC 3339 for APIs and JSON, RFC 2822 for email headers and HTTP. They describe the same instant with different syntax.
Set the moment and the zone
Choose the date, time and offset. Both formats carry an explicit zone, which is most of the reason to use them.
Copy the exact string
The output is character-for-character valid, including the separators and padding that strict parsers insist on.
Check an existing value
Paste a timestamp you have been given to confirm it conforms before you spend time debugging the other end.
RFC 3339, RFC 2822, and which one an API wants
RFC 3339 is the format most modern APIs mean when they say "ISO 8601". It is a deliberately restricted profile of ISO 8601 — 2026-07-25T14:30:00Z — that removes the optional variations the full standard permits, so every implementation agrees on how to parse it. When a specification says timestamps must be RFC 3339, it is asking for that strictness.
RFC 2822, and its predecessor RFC 822, define the format used in email headers and inherited by HTTP: Sat, 25 Jul 2026 14:30:00 +0000. It reads naturally to a person and is fixed-width in most of its fields, but it is not sortable as text and it carries English day and month abbreviations, which makes it a poor choice for anything new.
The two are not interchangeable and the difference is not cosmetic. A Date header in an email must be RFC 2822; a created_at field in a JSON API should be RFC 3339. Sending the wrong one usually produces a parse error, and occasionally something worse — a lenient parser that accepts it and gets the value wrong.
One subtlety in RFC 3339 worth knowing: -00:00 and +00:00 are not the same. +00:00 asserts the instant is genuinely in UTC, while -00:00 means the offset of the original local time is unknown. Almost nothing uses the distinction, but strict validators do check it.
When you'd reach for it
Calling a strict API
Produce a timestamp that passes validation on the first attempt.
Setting email headers
Generate a conforming Date header when constructing a message.
Writing HTTP headers
Format Last-Modified and Expires in the syntax the specification requires.
Debugging a rejected request
Compare your timestamp against a known-good one to find what the parser objected to.
Writing a parser
Generate valid and edge-case inputs to test against.
Converting between the two
Move a value from an email header into an API payload without hand-editing it.
Questions & answers
- When do I use RFC 3339 vs RFC 2822?
- RFC 3339 (a strict ISO 8601 profile) is standard for JSON APIs and internet protocols. RFC 2822/5322 is the human-readable format used in email headers and, in GMT form, the HTTP Date header.
- Why does the HTTP Date header say GMT?
- The HTTP specification requires the Date header in GMT (equivalent to UTC), formatted as an RFC 1123 date — which is what the tool emits.
- Does 'now' keep updating?
- Yes. With 'now' selected the outputs tick live every second; switch to a fixed date to format a specific moment.