What Makes a Valid ICS File?

The shape of a valid file

An ICS file is plain text. You can open it in a text app. You should see short lines of text. You should not see a web page.

The file starts with one line. That line says BEGIN:VCALENDAR. The file ends with one line too. That line says END:VCALENDAR. All events sit inside that wrap.

Each event sits in its own block. The block starts with BEGIN:VEVENT. The block ends with END:VEVENT. One file can hold many blocks. Each block is one stay or one block.

BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Your Tool//EN
BEGIN:VEVENT
UID:stay-1042@example.com
DTSTAMP:20261103T120000Z
DTSTART;VALUE=DATE:20261220
DTEND;VALUE=DATE:20261227
SUMMARY:Blocked - Guest stay
END:VEVENT
END:VCALENDAR

Look at the top lines first. VERSION tells the app the rules in use. Most files use version 2.0. PRODID tells which tool made the file. It is a name tag for the tool.

These two lines seem small and dull. But apps look for them at once. If they are gone, the file can fail. If they are wrong, the file can fail too.

The wrap must be whole and clean. Do not add text above the first line. Do not add text below the last line. Do not leave a block half open.

Think of the wrap as an envelope. The events are notes inside it. A torn envelope can lose the notes. A sealed one keeps them safe in transit.

File type matters less than file content. Some feeds end in .ics. Some feeds use a long web link. The link can hide a token in it. Keep that link private at all times. Only test feeds you own or may use.

If the link gives you a login page, stop. That is not a valid feed file. You can read more in our guide to a feed that returns an empty file. That case needs a fix at the source.

You do not need to code by hand. Your booking tool should build this shape. Your job is to spot when it does not. A quick look can save a lost night.

Open the file and scan the top. Then scan the end of the file. Then pick one event in the middle. Check that its block is whole and closed.

• First line says BEGIN:VCALENDAR
• Last line says END:VCALENDAR
• Each event block opens and closes
• No web page code in the file
• No text outside the main wrap

That scan takes less than one minute. It tells you if the shape is sound. Next you check the parts inside. Those parts do the real work each day.

The parts every event needs

Each event needs a small set of parts. Miss one part and the app may guess. A guess can shift or drop the stay. These parts are not extra flair.

UID is the ID for that one event. No two events should share one UID. Keep the same UID when you edit it. The app then knows it is the same stay.

If you make a new UID each time, harm follows. The app may add the stay twice. It may keep the old stay as well. That is how double blocks start to grow.

DTSTAMP is a stamp in UTC time. It shows when the event was built. It is not the start of the stay. Do not change it to the check-in date.

DTSTART is the start of the stay. DTEND is the end of the stay. For a full-day stay, use dates. For a timed stay, use date and time.

Be clear on how dates work here. The end date is the day you leave. It is not the last night you sleep. A stay from the 20th to the 27th blocks nights to the 26th.

That rule trips up many new hosts. They set the end to the last night. Their feed then frees the last night. A new guest can book that night.

Time zones need care as well. A timed event can carry a TZID tag. That tag names the zone for the time. If the tag is wrong, the time will shift.

Daylight saving adds one more trap. Clocks move in spring and fall. A fixed offset can then be wrong. Use a named zone when you can.

SUMMARY is the short title you see. Keep it short and clear for staff. Do not put guest names in it. Do not put phone codes or door codes in it.

Feeds travel to many apps and sites. Staff and guests may see the title. Safe titles protect guest privacy well. Use words like Blocked or Guest stay.

You can learn to find and fix broken events step by step. Start with the UID and dates first. Those three parts cause most of the pain.

• One UID per event, kept the same
• DTSTAMP in UTC, not check-in time
• DTSTART before DTEND at all times
• End date is the day of exit
• Short title with no private data

Check five events at random each month. Old events can hold old flaws in them. New events can copy those flaws fast.

Rules that are easy to break

The shape can look right and still fail. Small text rules sit under the shape. Apps read these rules in a strict way. A loose file can break a strict app.

Line length is the first such rule. No line should pass 75 octets. An octet is close to one byte. Long lines must be split or folded.

Folding has its own clear rule. You split the line at a safe point. The next line starts with one space. That space tells the app to rejoin them.

Do not just press Enter and type on. The app will read two lines, not one. It may cut the text in half. It may drop the rest of the line.

Line ends are the next rule. Each line must end with CRLF. That is a pair of control marks. Most tools add them for you in the file.

You break this rule when you edit by hand. A plain text app may save with new ends. The file then looks fine to your eye. But a strict app may read it as one blob.

So do not edit a live feed by hand. Fix the stay in your main tool. Then let that tool build the file anew. That keeps line ends and folds right.

Punctuation needs care inside text fields. Commas and semicolons have a job here. In some fields they split lists of values. A plain comma can be read as a split.

To use one as plain text, escape it. You put a backslash just before it. The same rule holds for semicolons too. It also holds for a new line in text.

• Comma in text is written as \,
• Semicolon in text is written as \;
• New line in text is written as \n
• Backslash in text is written as \\

Dates and times have a strict form. A date is year, month, then day. It uses no slashes and no dashes. A time adds hours, mins, and secs.

Do not write Dec 20 in the file. Do not write 20/12/2026 in the file. Apps do not guess such forms well. They may skip the event or shift it.

UTC times end with the letter Z. That Z means the time is in UTC. Do not add Z to a local time. That one letter can shift a stay by hours.

Text must use the right character set. Most apps expect UTF-8 text now. Names with accents can break old tools. If a name breaks the file, shorten the title.

Blank lines inside a block cause harm too. A blank line can look like an end. Keep blocks tight with no blank lines. Keep one event after the next in order.

You can check an iCal feed for errors in one pass. A check flags long lines and bad dates. It flags missing parts and bad escapes too. Fix the flags in the order they appear.

These rules feel strict for a reason. Many apps read the same one file. A strict form lets each app agree. Loose forms let each app guess in its own way.

Valid is not the same as useful

A file can pass all format rules. It can still hold the wrong dates. It can still miss a real stay. Valid means the form is right, not the facts.

Your tool may export old stays as new. It may export a test stay by mistake. It may export the wrong home in the feed. Each file can still be valid in form.

So check form and facts as two steps. Step one asks if apps can read it. Step two asks if the stays are true. You need a yes to both steps.

Look at the event count in the file. Does it match your list of stays? Look at the first and last stay dates. Do they match what you expect to see?

Open the timeline view if you have one. Gaps stand out fast in a timeline. Clashes stand out fast there too. Text lists hide gaps more than views do.

CalendarCheck checks content you paste or upload. It flags errors and warnings for you. It shows an event timeline as well. That helps you see gaps and clashes fast.

Know what a check cannot prove for you. It does not contact Airbnb or Vrbo. It cannot prove a platform refreshed your feed. Only the platform can show its own refresh.

Feed links can hold private tokens in them. Do not post a feed link in a public place. Do not share it in a group or forum. If it leaks, reset it in your tool at once.

Hosts ask how much check is enough. Check when you add a new feed link. Check when you change tools or homes. Check when a guest reports a wrong date.

Check after a time zone change as well. Spring and fall shifts catch many hosts. A stay near the shift needs a close look. Its start time may move by one hour.

The free preview covers one feed monitor. Paid Multi-feed covers up to ten monitors. It adds daily checks and email alerts. That fits hosts with more than one home.

Keep a short routine for each home. Save the feed link in a safe place. Note the date of your last good check. Note who can fix the source tool for you.

If dates still clash, use the ICS feed troubleshooting guide. Work from the source tool out to each app. Do not fix copies in five places at once.

A valid file is the base you need. True dates on top make it useful. Both steps keep nights blocked as sold. Both steps keep free nights open to book.

• Check form first, then check facts
• Count events and match your list
• View the timeline for gaps
• Keep feed links private and safe
• Recheck after each tool change

Make this a habit, not a one-off task. Feeds change each time a stay changes. A habit catches the next break early.

Questions about valid ICS files

Can I open an ICS file to read it?

Yes, you can open it as text. Use a plain text app to view it. Do not save edits from that app.

Does a valid file prove my dates are right?

No, it proves the form is right. You must still check dates and stays. Check the count and the timeline too.

Why does one app read it and one not?

Apps differ in how strict they are. A loose app may guess past a flaw. A strict app may reject the whole file.

Is a feed link safe to share with staff?

Share it with care if staff need it. The link can hold a private token. If it leaks, reset the link at once.

Sources and further reading

• IETF RFC 5545: iCalendar — the core rules for ICS files
• U.S. National Archives, Records Express: calendar formats guidance — plain notes on calendar file formats
• Iowa State University: iCalendar feeds tutorial — how iCalendar feeds work in use
• NIST: daylight saving time — when clocks shift in spring and fall
• IETF RFC 6868 — an update to RFC 5545 that defines how parameter values are encoded
• IETF RFC 7986 — standard properties for a whole calendar, such as NAME, UID, and REFRESH-INTERVAL