Certificate expiry countdown: sort your HTTPS certificates by time left

What you enter and what you get

Paste one certificate per line as the hostname, a comma and the date the certificate stops being valid (its not-after date), for example example.com, 2026-12-01T12:00Z. Choose how many days before expiry you want to renew and your time zone. The tool lists every line sorted by the time left at this moment, soonest first, with the exact time left, the renewal-by date and a flag: expired, under 7 days, under 30 days or under 60 days.

You can read the not-after date from the certificate in your browser's certificate viewer, from your host's control panel or from the output of your certificate tool. The tool does not connect to any server, so it cannot read the date for you.

• Accepted: YYYY-MM-DD, YYYY-MM-DDTHH:MM or YYYY-MM-DDTHH:MM:SS, each optionally followed by Z or a +HH:MM or -HH:MM offset.
• Not accepted: day-first or month-first dates such as 01/12/2026, month names such as Dec 1 2026, a space instead of the T, or an offset on a date with no time. Each is reported on its own line with the reason.
• Blank lines and lines starting with # are skipped. Up to 500 lines.

How the arithmetic works

A certificate is valid through its not-after instant and expired after it (RFC 5280 section 4.1.2.5). Time left is the not-after instant minus the current time on your device. A line with a Z or an offset is converted to the exact instant; a line with a time but no zone is read in the time zone you choose; a date with no time is read as the start of that day in UTC, the earliest it could mean, so the time left is never overstated (you can switch it to the end of the day). Renewal-by is the not-after instant minus your lead time.

The flags use these thresholds, which are this tool's own convention and not part of any standard: expired when the not-after instant has passed, under 7 days when less than 7 days remain, under 30 days when 7 or more but less than 30 remain, under 60 days when 30 or more but less than 60 remain. A value exactly on a boundary falls in the longer bucket.

• The default lead time is 30 days, which matches Let's Encrypt's advice to renew a 90-day certificate after 60 days.
• Lifetimes are getting shorter: the CA/Browser Forum's relevant-dates table lists maximum validity of 200 days from 15 March 2026, 100 days from 15 March 2027 and 47 days from 15 March 2029, so a lead time that suits a one-year certificate may not suit a shorter one.
• Let's Encrypt stopped sending expiry reminder emails on 4 June 2025, so an expiry list you keep yourself is a real control.

What this cannot know

It only knows the dates you typed. It cannot see which certificate a server is actually serving, whether automatic renewal is working, whether the certificate matches the hostname or whether the chain is trusted. A renewed certificate that was never installed still shows the old date on the live site. Check the served certificate with your browser or a command-line client before relying on a date. Fixed offsets do not follow daylight saving, and the clock on your device decides what 'now' means.

• The same hostname on two lines is kept as two lines, because they may be different certificates, and is pointed out.
• Wildcard names such as *.example.com are accepted.

Privacy and scope

The list stays in this page. It is not sent anywhere, not stored and not added to the web address, so it will be gone when you close the page; copy the result if you want to keep it.

If you want this done for you

The linked outcome covers finding why the certificate expired, replacing it through your host, checking the renewal path where the host exposes it and setting an independent expiry warning. Send the hostname and the warning you see, not private keys or account passwords. Scope and price are agreed before work.