FreeToGenerate.com

A calendar file records the moment an event is already over, so a whole-day event ends on the following day. Nothing is uploaded.

Try one:

The last day the event actually covers. The file will record the day after this one, and the panel below shows both numbers.

The two numbers

You said the event's last day is
7 August 2026
The file records an end of
DTEND;VALUE=DATE:20260808

Those are the same event. The end recorded in a calendar file is the moment the event is already over, so a whole-day event ends on the following day. Write the day you meant and the event comes out a day short - which is the commonest thing to get wrong here, and it does not look wrong in any editor.

When it happens

  1. 5 August 2026
  2. 5 August 2027
  3. 5 August 2028

The first entry is the start date itself. That is the rule, not an off-by-one: a count of three means the start plus two more.

The file

Longest line: 43

These are the exact bytes, folded where the specification asks for it. Long lines are broken and continued with a leading space; a reader joins them back up before doing anything else.

Everything here runs in your browser. Nothing you type is uploaded.

Also available in: Español · Português · Français · العربية

ICS file generator: the end date is the day after

Fill in an event, get a valid .ics file, and see both numbers — the last day you named and the end the file actually records.

What is an .ics file?

An .ics file is a calendar event written as plain text. Every calendar program reads the format — Google Calendar, Outlook, Apple Calendar, Thunderbird — because it is a published standard rather than any one company's format, which is why an event mailed as an attachment opens for everyone. Inside it is a list of lines: a title, a start, an end, optionally a repeat rule, each written as a name, a colon and a value.

It is also a format with a famous trap in it, and this generator is built around showing you that trap rather than quietly getting it right on your behalf. The end recorded in a calendar file is not the last moment of the event. It is the first moment after the event, which the standard calls the non-inclusive end. For a timed meeting nobody notices: an event ending at 10:00 is over at 10:00 and that is what everyone expects. For a whole-day event it bites, because a festival that runs Wednesday to Friday has to be written as ending on Saturday.

The specification itself works that example, and the numbers are worth having: an event running from 28 June to 8 July 2007 inclusive is written with an end of 9 July. Get it wrong and the file is one day short. Nothing warns you, no calendar refuses it, and the event simply appears with its last day missing.

How to use it

  1. Describe the event. A title, and optionally a location and a description. Choose whole days or a specific time; if you pick a time, choose how it should be recorded — unmoored local time, an absolute instant, or a wall-clock time in a named zone that the tool converts for you.
  2. Name the last day it runs. The field asks for the last day the event actually covers, because that is the thing a person knows. The panel underneath shows that date beside the end the file records, which is the day after. Both numbers are on screen at once so the conversion is visible rather than something you have to trust.
  3. Copy the bytes or download the file. The output is shown exactly as written, including where long lines are broken and continued. Read a file the other way too: switch to reading mode, paste one in, and it will tell you what each date actually means and what the last day really is.

Two bounds, and they disagree

The same format bounds two things and uses opposite conventions for them. An event's end is exclusive, as above. A repeat rule's end date is inclusive — the standard says it bounds the recurrence in an inclusive manner, so a weekly meeting that ends on 2 September happens on 2 September. Set both on the same event and you are writing one date that means up to and a second date that means through, a few lines apart, with nothing in the syntax to distinguish them.

A repeat counted by number has its own quiet rule: the start counts as the first occurrence. Asking for three means the start plus two more, not the start plus three. That is why this tool lists the occurrences rather than telling you about them — the first row is the start date, and once you have seen it you will not misread a count again.

None of this is a defect in anyone's software. The libraries that build these files take whatever end you hand them and write it down, which is exactly what they should do. The mistake happens one level up, in the gap between what a person means by ends on Friday and what the format records, and no library can close that gap for you because it never sees what you meant.

Why there is no zone name in the file

If you enter a time in a named zone, this tool works out the instant it corresponds to and records that. It does not write the zone's name into the file, and the reason is worth stating plainly: the format does allow a date to reference a zone by name, but only if the file also carries that zone's complete definition — every daylight-saving rule, written out as its own block. A name with no definition is not a shortcut, it is a file whose meaning depends on software you cannot inspect.

Recording the instant is exact, needs nothing else, and every calendar will show it in the reader's own zone. It has one honest cost, which the standard's design makes unavoidable: a repeating meeting pinned to an instant does not follow a zone across a daylight-saving change. A weekly nine o'clock in Paris, recorded that way, reads as eight o'clock the week after the clocks go back — computed, not guessed. If a recurring meeting must stay at the same local hour all year, that is the case where a full zone definition genuinely earns its place.

Two smaller things the tool handles rather than mentions. A wall-clock time you type may not exist — the clocks jump over it in spring — or may happen twice, on the day they go back. Both are reported when they arise, with the reading used stated, instead of silently picking one.

What the tool will not tell you

It does not check that your event makes sense. A meeting that ends before it starts, a title of nothing at all, a repeat that runs for a century — all of those produce a perfectly valid file, because valid here means well formed rather than sensible. The reading mode reports the things that are decidable from the text alone, and stops there.

It writes one event. A calendar file may hold many, along with alarms, attendees, free-busy blocks and attached documents, and this generator covers none of that. It also writes a fixed timestamp rather than the current moment, since that field records when the description was produced and has no bearing on when the event happens.

Long lines are broken and continued because the standard asks for lines of at most 75 bytes. Bytes, not characters — which is why a title in English can be nearly twice as long as one in French or Arabic before it needs breaking, and why a tool that counts characters instead sails past the limit on any accented text without ever looking wrong. The count under the output is measured in bytes, so you can watch it.

Why is it free?

Building a calendar file is text assembly. It runs in your browser, so there is no server in the path, nothing to meter and no account to create.

Nothing is uploaded. What you type, and any file you paste in to read, stays in this tab.