OneWebDesk

Signed URL Expiry Calculator

Compute signed URL expiry considering duration and clock skew.

CDNs and object storage such as CloudFront, S3, and Cloudflare hand out signed URLs (or presigned URLs) that embed an expiry time to grant temporary access. Enter a start time and a validity duration, and this calculator converts it into the exact expiry as a UTC ISO 8601 string, a local time, and a Unix epoch (seconds) all at once.

When the signer's clock and the verifier's clock drift apart, a URL that should still be valid can be rejected as expired, or one that should be dead can linger. Provide a clock skew allowance and the tool also computes the effective expiry you can safely rely on. Everything runs in your browser; no value is ever sent anywhere.

How signed URL expiry is computed

The formula is simple: expiry = start time + duration. Most signing schemes encode the expiry as an absolute time (Unix epoch seconds) in the URL. CloudFront uses the policy DateLessThan value; an S3 presigned URL uses X-Amz-Expires (seconds) relative to when it was signed.

  • Start time: usually "now" when you sign the URL, but you can pre-issue with a future start.
  • Duration: entered in seconds, minutes, hours, or days. S3 presigned URLs cap at 7 days (604800s).
  • Expiry: after this, the gateway rejects the request with 403.

Always account for clock skew

The clock that verifies the signature is never perfectly in sync with the one that created the URL. If the verifier's clock runs slightly fast, a URL that the signer still considers valid may already look expired to the verifier. So treat the effective expiry conservatively.

  • Effective expiry = expiry − skew allowance. Design requests to arrive before this moment.
  • Even with NTP, a few seconds of drift is common. A 1–5 second buffer is a safe starting point.
  • Conversely, if your signature has a future start (NotBefore), a slow verifier clock may reject it as "not yet valid," so add the same kind of buffer there too.

Operational tips

  1. Keep expiries short. If a URL leaks, a small window limits the damage.
  2. For long downloads/uploads, the duration must comfortably exceed the full transfer time (whether expiry is checked only at connection start or continuously varies by service).
  3. Store times as UTC epoch in logs and databases; convert to local time only for display. To turn a stored epoch back into a human-readable time, the log timestamp converter is handy.

To also design CDN cache freshness (TTL) and background-refresh policy, see the stale-while-revalidate planner.

Frequently asked questions

What happens if I leave the start time empty?
Click the Now button or type a datetime to set the start. With nothing set, no result is shown. Since URLs are usually issued relative to now, press Now to begin.
What is the maximum validity for an S3 presigned URL?
Under SigV4 the maximum is 7 days (604800 seconds). Longer access is also bounded by the lifetime of any temporary IAM credentials, so consider a different auth method if you need more.
What clock skew allowance should I use?
For well-synced (NTP) servers, 1–5 seconds is often enough. For mobile or embedded clients whose clocks may be unreliable, some teams extend it to 30–60 seconds.
Are my times or URLs sent to a server?
No. Everything is computed locally with the browser's JavaScript Date object; nothing leaves your device.
What time zone does the local time use?
It follows this browser/device's time zone setting. The UTC ISO value and the epoch are absolute and time-zone independent, so use the epoch when comparing across systems.

Related tools