Skip to content
AZ Tools

Duration Formatter

Convert a duration between human ("1h 30m"), clock (1:30:00), ISO 8601 (PT1H30M), and raw seconds/minutes/hours/days.

Human

1 hour 30 minutes

Short

1h 30m

Clock

1:30:00

ISO 8601

PT1H30M

Seconds

5400 s

Minutes

90 min

Hours

1.5 h

Days

0.0625 d

Calendar-relative units (weeks, months, years) aren't supported — their length depends on the date.

How to use

  1. Type a duration: "1h 30m", "5400", "01:30:00", or "PT1H30M".
  2. Read off the equivalent in every other format.
  3. Copy whichever representation you need.

About this tool

Show

Type a duration in any common form — 2d 4h, 90 min, 5400 seconds, 01:30:00, or the ISO 8601 string PT1H30M — and see every other representation at once, so you can move between log output, an API field, a video timestamp and a sentence a person will read without doing the arithmetic. A bare number is read as seconds, the clock form accepts h:mm or h:mm:ss, and the written form understands days, hours, minutes, seconds and milliseconds under their usual abbreviations. The ISO side deliberately stops at days: weeks, months and years have no fixed length, so a duration that included them could not be converted to seconds without inventing a calendar to measure it against.

Frequently asked questions

What units does the human format accept?

Days (d/day), hours (h/hr/hour), minutes (m/min/minute), seconds (s/sec/second), and milliseconds (ms). Plurals work. Order doesn't matter — "30m 1h" parses fine.

What does a bare number mean?

A bare number (e.g. 90) is interpreted as seconds. Use 90 min or 90:00 if you mean minutes.

Does it support negative durations?

Yes — prefix with -. Useful for representing offsets like "finishes 5 minutes early".

What ISO 8601 forms are accepted?

The P[D]T[H][M][S] shape used in APIs like Google Calendar and YouTube — e.g. PT1H30M, P1DT2H, PT45S. Weeks (W) and the larger years/months are not supported because their length depends on the calendar.

Why does 1:75 fail but 75:00 work?

The clock parser constrains only the trailing fields to 00-59; the leading field is unbounded. So 75:00 is 75 minutes, 100:30:00 is 100 hours 30 minutes, and 1:75 is rejected because 75 sits in a minute slot. That matches how stopwatch and ffmpeg output is usually written — the largest unit carries the overflow.

Where does the precision stop?

The human and short forms round seconds to two decimals, the clock and ISO forms to three, and the decimal rows to 3 (s), 4 (min), 4 (h) and 6 (d) places. A 1.5 ms input therefore reads 0.00s in human form but PT0.002S in ISO. For anything under about 10 ms, read the seconds row rather than the worded one.

Related tools