Gregorian to Julian calendar date converter
Enter a Gregorian date and see how the same day is written in the Julian calendar: 7 August 2026 is 25 July, 13 days behind. The offset is shown for every date, because it changes across the centuries. Free in your browser.
- Free
- Runs in your browser
- No sign-up
- Your data stays on your device
Run — free
Worked example
- Date
- 2026-08-07
- Gregorian date
- 2026-08-07
- Julian date
- 2026-07-25
- Day offset
- 13
This Gregorian to Julian calendar date converter accepts one explicit date in YYYY-MM-DD form and returns the calendar date that identifies the same civil day under the Julian calendar. It also reports the day offset applicable to that year, making changes across centuries visible instead of hiding them behind a simple subtraction. The calculation uses bounded integer calendar arithmetic, validates Gregorian leap days, and never reads a clock, time zone, network service, or runtime date parser.
Understand what the conversion means
The Gregorian and Julian calendars assign different labels to the same continuous sequence of days because their leap-year rules are not identical. This tool treats the supplied value as an explicit Gregorian calendar date and finds the Julian calendar label for that exact day. For example, Gregorian 1582-10-15 corresponds to Julian 1582-10-05, while a modern Gregorian date is normally thirteen days ahead of its Julian label.
Every valid input is interpreted using the proleptic Gregorian rules, even if it predates a region's civil reform. That explicit policy makes historical datasets reproducible and prevents a hidden locale assumption from changing an answer.
Supply and validate the Gregorian ISO date
Send an object with a date field containing exactly four year digits, two month digits, and two day digits separated by hyphens. Supported years run from 0001 through 9999. The parser rejects missing values, extra time text, informal month names, impossible months, and impossible days.
Gregorian leap-year validation is applied before conversion: a year divisible by four is usually a leap year, a century year is not, and a century divisible by four hundred is. Consequently 2000-02-29 is accepted, whereas 1900-02-29 is rejected. Once validated, the date is converted to an integer Julian Day Number using Gregorian arithmetic.
That integer is then decoded with Julian calendar arithmetic.
Use deterministic results in historical workflows
Calendar conversion appears in archive catalogues, genealogy projects, historical timelines, church records, and integrations with organizations that still publish Julian calendar observances. In all of these settings, write down which calendar the source uses before converting anything. Feed only a date known to be Gregorian into this capability; a Julian source date needs the opposite conversion and should not be passed here merely because it has ISO-shaped digits.
The algorithm is deterministic and has no network dependency, random choice, current-date lookup, or regional reform table. However, historical documents may use local adoption rules, regnal years, religious new-year conventions, or ambiguous handwritten dates. Resolve those source questions before calling the converter.
For large migrations, test representative dates around leap days and century boundaries before processing the full collection.
What you can do with it
Normalize archival dates
Add the corresponding Julian calendar label to records whose source date is explicitly Gregorian.
Prepare historical timelines
Show parallel Gregorian and Julian dates while preserving the changing offset across centuries.
Test calendar software
Create repeatable conversion checks around reform dates, leap days, and century boundaries.
FAQ
Does this return a Julian Day Number?
No. It returns a date in the Julian calendar that corresponds to the supplied Gregorian calendar date.
Does the calculation depend on my time zone?
No. It uses integer calendar arithmetic and does not use Date, clocks, time zones, or daylight-saving rules.
Are dates before 1582 supported?
Yes. They are interpreted under proleptic Gregorian rules, giving a consistent conversion rather than a country-specific adoption policy.
Why is the difference not always 13 days?
Because the two calendars disagree on century leap years. The gap grows over the centuries, so the result reports the offset for each date instead of assuming 13; on 15 October 1582, for example, it was ten days.
Can I convert a Julian date back to Gregorian here?
No. This tool only reads Gregorian dates. A date taken from a Julian source needs the opposite conversion, even if its digits look the same, so check which calendar your source uses first.
Related tools
For developers — API access
Everything on this page is available programmatically. This section is for teams who want to wire it into their own systems; everyone else can just use the tool above.
API endpoint
Prefer to automate it? One authenticated POST creates the task; the result comes back by webhook or a signed link. The same capability also runs here on the web, by email and from Telegram — and soon from our app too.
Call it from your stack
curl -X POST https://api.kit.forhosting.com/date/gregorian-to-julian-cal \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"date":"2026-08-07"}'const res = await fetch("https://api.kit.forhosting.com/date/gregorian-to-julian-cal", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.KIT_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
"date": "2026-08-07"
})
});
const { task_id } = await res.json();import os, requests
res = requests.post(
"https://api.kit.forhosting.com/date/gregorian-to-julian-cal",
headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
json={
"date": "2026-08-07"
},
)
task_id = res.json()["task_id"]<?php
$res = file_get_contents("https://api.kit.forhosting.com/date/gregorian-to-julian-cal", false, stream_context_create([
"http" => [
"method" => "POST",
"header" => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
"content" => '{"date":"2026-08-07"}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"date":"2026-08-07"}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/date/gregorian-to-julian-cal", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)Example request
{
"date": "2026-08-07"
}Example response
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "date.gregorian_to_julian_cal",
"status": "queued",
"_links": {
"result": "/tasks/tsk_…/result"
}
}The API is asynchronous: the call returns a task_id immediately and the result arrives by webhook. Polling is capped at 1 req/s per task.
Pricing
Published price — no tokens, no invented credits. A failed task is never charged.
Errors
| HTTP | Code | Meaning |
|---|---|---|
401 | unauthorized | Missing or invalid API key. |
402 | insufficient_balance | Your balance doesn't cover the task price. |
404 | unknown_type | That task type doesn't exist. |
429 | rate_limited | Too many requests. Use the webhook instead of polling. |
Technical notes
Results are therefore repeatable in browser and API workflows.
Understand what the conversion means
The returned day_offset expresses that relationship as the number of days by which the Gregorian label is ahead when the same year, month, and day are compared in both calendars. This is a calendar conversion, not a conversion to Julian Day, Modified Julian Day, or an astronomical timestamp. It also does not imitate the adoption history of a particular country. Use the julian_date field as the corresponding calendar label and the offset as useful explanatory metadata.
Supply and validate the Gregorian ISO date
The response always contains gregorian_date, julian_date, and day_offset with stable field names. If validation fails, the API produces an invalid_input error with a direct explanation. This strict input contract is useful for imports because malformed source data fails visibly rather than being normalized into a different date without notice.
Use deterministic results in historical workflows
Keep the original gregorian_date beside julian_date so reviewers can trace the transformation, and retain day_offset when the dataset spans centuries because the difference is not constant over all years. The price for an API request is $0.002; the browser execution uses the same pure calculation.
Technical questions
What does day_offset mean?
It is the number of days by which the Gregorian calendar label is ahead of the Julian label for the relevant period.
How much does an API conversion cost?
Each API request costs $0.002. The same deterministic calculation can run in the browser.