Milliseconds to Seconds — A Developer's Time Conversion Reference

Milliseconds come up constantly in software development. A timeout is set to 5000ms. An API rate limit says "100 requests per 10 seconds." An animation runs for 300ms. A Unix timestamp is in milliseconds in JavaScript but seconds in Python. The conversions are simple — 1 second = 1,000 milliseconds — but having the common values at hand saves the mental overhead.

The Time Converter handles milliseconds, seconds, minutes, hours, and more. This article is a practical reference with the values developers encounter most often.

The Basic Conversion

1 second = 1,000 milliseconds

1 millisecond = 0.001 seconds

seconds = milliseconds ÷ 1,000

milliseconds = seconds × 1,000

Everything else follows from this:

  • 1 minute = 60,000 ms
  • 1 hour = 3,600,000 ms
  • 1 day = 86,400,000 ms

Common Values in Code

These are the values you will type or encounter regularly:

DurationMillisecondsSeconds
One frame at 60fps~16 ms0.016 s
Animation transition (fast)150–200 ms0.15–0.2 s
Animation transition (normal)250–300 ms0.25–0.3 s
Animation transition (slow)400–600 ms0.4–0.6 s
Average human reaction time~250 ms0.25 s
HTTP request timeout (fast)1,000 ms1 s
HTTP request timeout (standard)5,000 ms5 s
HTTP request timeout (generous)30,000 ms30 s
Rate limit window60,000 ms60 s (1 min)
JWT token expiry (short)900,000 ms900 s (15 min)
JWT token expiry (standard)3,600,000 ms3,600 s (1 hr)
Daily rate limit window86,400,000 ms86,400 s (24 hr)
Session timeout (standard)1,800,000 ms1,800 s (30 min)

Reference Table: Seconds to Milliseconds

SecondsMilliseconds
0.1 s100 ms
0.25 s250 ms
0.5 s500 ms
1 s1,000 ms
2 s2,000 ms
5 s5,000 ms
10 s10,000 ms
15 s15,000 ms
30 s30,000 ms
60 s (1 min)60,000 ms
120 s (2 min)120,000 ms
300 s (5 min)300,000 ms
600 s (10 min)600,000 ms
900 s (15 min)900,000 ms
1,800 s (30 min)1,800,000 ms
3,600 s (1 hr)3,600,000 ms
86,400 s (1 day)86,400,000 ms

Milliseconds in Different Languages

Different languages and environments use different default time units. This is a common source of subtle bugs.

JavaScript: Date.now() returns milliseconds. setTimeout(fn, 5000) takes milliseconds. new Date().getTime() returns milliseconds.

const ts_ms = Date.now();                   // milliseconds
const ts_s = Math.floor(Date.now() / 1000); // seconds
setTimeout(fn, 5 * 1000);                   // 5 seconds in ms

Python: time.time() returns seconds (float). time.sleep(5) takes seconds.

import time
ts_s = time.time()          # seconds (float)
ts_ms = time.time() * 1000  # milliseconds
time.sleep(0.5)             # 500ms in seconds

Node.js process.hrtime(): Returns nanoseconds (very high precision). performance.now() returns milliseconds.

const start = performance.now();
// ... do something ...
const elapsed_ms = performance.now() - start;
const elapsed_s = elapsed_ms / 1000;

CSS animations and transitions: Use seconds as the unit.

transition: all 0.3s ease;      /* 300ms */
animation-duration: 1.5s;       /* 1500ms */

Redis TTL: EXPIRE key seconds — takes seconds, not milliseconds. PEXPIRE key milliseconds is the millisecond version.

cron expressions: Work in whole seconds at the finest granularity (some implementations, like Spring's @Scheduled, support seconds; standard unix cron is minute-granularity).

Unix Timestamps: Seconds vs Milliseconds

The most common cross-language bug involving milliseconds: Unix timestamps.

  • The Unix standard is seconds since epoch (January 1, 1970)
  • JavaScript's Date.now() is milliseconds since epoch
  • A seconds timestamp is 10 digits (currently ~1.7 billion)
  • A milliseconds timestamp is 13 digits (currently ~1.7 trillion)

If you send a JavaScript millisecond timestamp to a Python backend that expects seconds, you get a date in the year 55,000. If you send a seconds timestamp to JavaScript's new Date(), you get a date in 1970.

Detection heuristic:

  • 10 digits = seconds
  • 13 digits = milliseconds
// Normalize to seconds regardless of input format
function toSeconds(ts) {
    return ts > 9999999999 ? Math.floor(ts / 1000) : ts;
}

Performance Measurements

When profiling code or measuring execution time, milliseconds and microseconds come up depending on what you are measuring.

ScaleUnitExample use
< 1 msMicroseconds (µs)CPU operations, memory access
1–100 msMillisecondsDatabase queries, API calls, renders
100–1,000 msMillisecondsSlow queries, image processing
> 1 sSecondsPage load times, batch processing

For web performance:

  • < 100 ms: Feels instant
  • 100–300 ms: Noticeable but acceptable
  • 300–1,000 ms: Feels slow; spinner may be needed
  • > 1 s: User perceives as "loading"

Google's Core Web Vitals use milliseconds: Largest Contentful Paint (LCP) should be under 2,500ms, Interaction to Next Paint (INP) under 200ms, Cumulative Layout Shift is unitless.

Rate Limiting and Throttling

Rate limits are often expressed in requests per time window. Converting the window to milliseconds is useful for implementing throttle logic:

Rate limitWindow in msTime between requests
100 req/s1,000 ms10 ms minimum
60 req/min60,000 ms1,000 ms minimum
1,000 req/hr3,600,000 ms3,600 ms minimum
10,000 req/day86,400,000 ms8,640 ms minimum

A simple throttle implementation uses the window in milliseconds:

const RATE_LIMIT_WINDOW_MS = 60 * 1000; // 60 seconds
const MAX_REQUESTS = 60;
// one request per 1000ms on average
const MIN_INTERVAL_MS = RATE_LIMIT_WINDOW_MS / MAX_REQUESTS; // 1000

For any other time unit conversions beyond milliseconds — days to hours, weeks to minutes, years to seconds — the Time Converter covers the full range.

Related articles