DEV Community: Toolsy Hub

Is this timestamp in seconds or milliseconds? Guessing the unit from the digit count

Toolsy Hub — Thu, 12 Nov 2026 03:48:48 +0000

You paste 1700000000 into a date converter and get November 2023. You paste 1700000000123 and get the same day, but only if the tool knows the second number is milliseconds. Feed that value to code that expects seconds and you get a year about 53,000 years from now. Feed the first value to new Date() and you get January 1970.

new Date(1700000000 * 1000).toISOString() // "2023-11-14T22:13:20.000Z"
new Date(1700000000).toISOString()        // "1970-01-20T16:13:20.000Z"

The second line is the classic bug: seconds passed where JavaScript wants milliseconds. The date lands 19 days after the epoch, which looks plausible enough to survive a code review.

Count the digits

Today a timestamp in seconds has 10 digits, milliseconds has 13, microseconds 16 and nanoseconds 19. That is enough to guess the unit when you cannot ask where the number came from. The converter on Toolsy Hub uses this rule on the whole part of the number:

up to 11 digits: seconds (this holds until the year 5138)
12 to 14 digits: milliseconds
15 to 17 digits: microseconds
18 or more: nanoseconds

The cut points sit between the common lengths, so a 12 or 14 digit value still gets a sensible unit. It is a guess, so the tool also lets you pick the unit by hand.

Why nanoseconds need BigInt

A nanosecond timestamp for today is around 1.7 x 10^18. JavaScript numbers are 64-bit floats and only hold whole numbers exactly up to 9,007,199,254,740,991. Past that, digits get rounded:

Number(1700000000123456789n)   // 1700000000123456800
1700000000123456789n.toString() // "1700000000123456789"

So the converter keeps every input as whole nanoseconds in a BigInt and only turns it into a Date at the last step, after dividing down to milliseconds. Microsecond and nanosecond input comes out exact.

Negative timestamps round the other way

Dates before 1970 are negative. Truncating division gets them wrong by a second:

Math.trunc(-1500 / 1000) // -1  (rounds toward zero)
Math.floor(-1500 / 1000) // -2  (rounds toward the past)

-1500 ms is 1.5 seconds before the epoch, which falls inside the second that starts at -2. BigInt division truncates (-1500n / 1000n is -1n), so the converter has its own floor division that steps down by one when the remainder is not zero and the value is negative.

The range limit

A JavaScript Date stops at 8,640,000,000,000,000 ms either side of 1970. One millisecond past that is an invalid date:

new Date(8.64e15).toISOString()  // "+275760-09-13T00:00:00.000Z"
new Date(8.64e15 + 1).getTime()  // NaN

A converter should say "out of range" and not print "Invalid Date". The one on Toolsy Hub does, and it also rejects text that is not a number with its own message.

If you want to check a value without writing code, the converter is at https://www.toolsy-hub.com/tools/unix-timestamp-converter. It runs in the browser tab, shows seconds, milliseconds, microseconds, nanoseconds, ISO 8601 and UTC for any input, and converts a pasted list one value per line.

How to shrink a PDF to a target size in the browser: render pages, split a byte budget, retry three times

Toolsy Hub — Thu, 05 Nov 2026 09:36:33 +0000

Court portals, job sites and university forms often cap uploads at a number like 200 KB or 2 MB. Most PDF compressors give you a quality slider and leave you to guess. If you know the target, you can make the code hit it.

Here is how the Compress PDF tool on Toolsy Hub does it, all in the browser with pdf-lib and pdf.js.

Two modes, because they trade different things

Light re-saves the file with pdf-lib and object streams turned on. Text stays selectable and nothing is re-encoded, so the saving is small. If the PDF has pictures that are the real weight, light mode will not help.

Images renders every page to a JPEG with pdf.js and rebuilds the PDF from those pictures. A scanned document shrinks a lot. The cost is that text becomes part of the picture, so it is no longer selectable. The tool says this before you pick it.

Render once at the sharpest setting

There are three presets: 150 dpi at JPEG quality 0.8, 120 dpi at 0.65, and 96 dpi at 0.5. When you type a target size, the tool ignores the preset and starts every page at the sharpest one, 150 dpi at 0.8. It lowers quality only as far as the target needs. Starting low and going up would leave a sharp document blurry for no reason.

Split the byte budget by pixel area

If the first PDF is already under the target, you are done. If not, the target in bytes is divided across the pages in proportion to each page's pixel area (width times height). A big page gets a bigger share than a small one, so one large scan does not eat the whole budget.

Each page image is then recompressed to its share with a quality search, and the PDF is rebuilt.

Retry, but only three times

Page shares add up, but PDF structure adds overhead on top of the images, so the rebuilt file can land a little over. The tool then tightens the budget by target / size * 0.95, never by more than half in one step, and tries again. Three attempts at most. If it still misses, it hands back the smallest result and says the target was not reached, rather than looping or silently returning a file that breaks your limit.

The "say so" part matters. A file that is 30 KB over a 200 KB limit gets rejected by the portal, and the person finds out only after the upload fails.

What stays in the browser

Nothing is sent to a server for this. pdf-lib is loaded on demand (about 180 KB) so the page itself stays light. Files you add stay in your browser; Google Analytics counts visits to the site.

Try it: https://www.toolsy-hub.com/tools/compress-pdf. For a fixed limit there is a page with the size already set: https://www.toolsy-hub.com/tools/compress-pdf/200kb.

What I would improve: the retry factor is a heuristic. A proper search over per-page quality would hit the target more closely on files with mixed pages. If you have a PDF that misses its target, I would like to hear about it.

How to compress an image to an exact KB limit in the browser (canvas, binary search, and when to stop lowering quality)

Toolsy Hub — Thu, 29 Oct 2026 02:52:26 +0000

Upload forms for visas, exams and job portals often say "photo must be under 100 KB". A phone photo is 3 to 5 MB, and the usual advice is to drag a quality slider until the number looks right. You can automate that in the browser with the canvas API, and the part that matters is knowing when to stop lowering quality.

Encode at a quality and read the size

canvas.toBlob(callback, "image/jpeg", quality) gives you a Blob. blob.size is the file size in bytes. That is all you need to measure.

function encode(bitmap, width, height, quality) {
  const canvas = document.createElement("canvas")
  canvas.width = width
  canvas.height = height
  const ctx = canvas.getContext("2d")
  ctx.fillStyle = "#fff" // JPEG has no alpha; transparent PNGs turn black without this
  ctx.fillRect(0, 0, width, height)
  ctx.imageSmoothingQuality = "high"
  ctx.drawImage(bitmap, 0, 0, width, height)
  return new Promise((resolve) => canvas.toBlob(resolve, "image/jpeg", quality))
}

Load the bitmap with createImageBitmap(file, { imageOrientation: "from-image" }), otherwise phone photos come out sideways because the EXIF rotation is ignored.

Binary search on quality

File size grows with quality, so you can search for the highest quality that still fits:

let low = 0.3, high = 0.95, best = null
for (let i = 0; i < 6; i++) {
  const q = (low + high) / 2
  const blob = await encode(bitmap, w, h, q)
  if (blob.size <= targetBytes) { best = blob; low = q } else { high = q }
}

Six rounds narrows the range to about 1% of quality, which is more precision than the file size needs. Count 1 KB as 1000 bytes, not 1024, so the file passes whether the form counts KB one way or the other.

Know when to stop

Here is the part the sliders do not tell you. Below roughly 30% JPEG quality a photo breaks into visible blocks and the colours shift. A file that is technically under the limit but looks like that gets rejected by a human reviewer or looks bad on an ID. So the search never goes below 0.3. First it encodes once at 0.3 for the current size. If that is still over the limit, it makes the picture smaller instead: width and height times 0.8, and try again. It tries up to 12 sizes, which is down to about a tenth of the original width. Only at the last size does it allow quality all the way down to 0.05, because a file that fits beats no file.

PNG has no quality setting, so for PNG only the dimensions change.

What I would do differently

Offer a "keep exact width and height" switch for forms that demand fixed pixels, and then accept a lower quality or a missed target. The tool I built has one, and it tells the user when the target was missed.
Test the search with a fake encoder. The function takes the encoder as a parameter, so unit tests can pass a function that returns a Blob of a size you choose, with no canvas involved.

The tool built on this, with nothing uploaded anywhere:

Image compressor with a target size: https://www.toolsy-hub.com/tools/image-compressor
Photo resizer for exact KB and pixel presets: https://www.toolsy-hub.com/tools/photo-signature-resizer

Google Analytics counts visits on the site; image files are never sent anywhere.

Building PDF tools that never upload your file: pdf-lib, pdf.js and qpdf in WebAssembly

Toolsy Hub — Thu, 22 Oct 2026 14:16:17 +0000

Most "free PDF tools" upload your file to a server, process it there and send it back. For a bank statement or a CNIC scan that is a lot of trust to hand a site you found a minute ago. I wanted merge, split, compress and unlock to work with no upload at all, so I built them to run entirely in the browser. This post is what that took, and where it falls short.

The three engines

pdf-lib (1.17) reads and writes the PDF structure: merging, splitting, picking pages, building a PDF from JPGs. It is plain JavaScript and works the same in every modern browser.
pdf.js (Mozilla's renderer) draws a page onto a canvas. I use it to turn pages into images for "PDF to JPG" and for the stronger compress mode.
qpdf, compiled to WebAssembly (about 1.3 MB), removes the password and restrictions from a PDF when the user types the password they already know. pdf-lib cannot decrypt, so this is the one job that needed a native tool.

None of them load with the page. Each is imported inside the click handler with await import(...), so someone who only wants the word counter never downloads a PDF engine.

Caching the engines for a year

The WASM and worker files are copied at build time into a folder named after the package version, for example /engines/qpdf-<version>/, and served with Cache-Control: public, max-age=31536000, immutable. A new version gets a new folder, so a browser never mixes an old worker with new code, and a returning visitor does not download 1-2 MB again.

Compress: two modes, and why

There is no magic "compress PDF" call. What shrinks a PDF depends on what is inside it.

Light mode re-saves the file with pdf-lib using compressed object streams. Text stays selectable. The saving is small, often a few percent, because the pictures inside are untouched.
Image mode renders every page with pdf.js to a JPEG (150 dpi at quality 0.8 for "high", down to 96 dpi at 0.5 for "low") and builds a new PDF from those images. For scanned documents, which are pictures anyway, this is where the big savings are. The cost: text becomes part of the picture and is no longer selectable.

The tool says which mode does what before you click, rather than after.

Hitting an exact size

Upload forms in Pakistan ask for "PDF under 200 KB" or "under 100 KB", so a slider is not enough. With a target set, the pages are rendered at the sharpest level first, and the packer lowers JPEG quality only as far as it has to until the whole PDF fits. If it cannot get there, it says so instead of quietly handing back a file that is still too big.

What does not work well

Very large files on phones. Rendering 60 pages at 150 dpi in a phone browser uses a lot of memory. Server tools win here.
Image mode on text PDFs. A text-only PDF can come out bigger as images. Light mode is the right choice there. Image mode is still the default, because most files people bring to a "PDF under 200 KB" form are scans.
Password cracking. The unlock tool opens a file with the password you type. It does not guess passwords, on purpose.

Try it

The tools are free with no sign-up: Compress PDF, Merge PDF, Unlock PDF. Open the network tab while you use one and you will see no request carrying your file.

If you have built something similar, I would like to hear how you dealt with memory on phones.