The idea#

For one picture at one size, a JPEG's file size goes up as quality goes up. That makes it a search problem: find the highest quality whose file still fits under the limit. A binary search does it in a handful of tries.

async function bestQuality(encode, scale, maxBytes, low) {
  const top = await encode(scale, 0.92)
  if (top.size <= maxBytes) return { blob: top, scale, quality: 0.92 }
  const floor = await encode(scale, low)
  if (floor.size > maxBytes) return null // even the lowest quality is too big at this size
  let lo = low, hi = 0.92, best = { blob: floor, scale, quality: low }
  for (let i = 0; i < 7; i++) {
    const mid = (lo + hi) / 2
    const blob = await encode(scale, mid)
    if (blob.size <= maxBytes) { best = { blob, scale, quality: mid }; lo = mid }
    else hi = mid
  }
  return best
}

Seven halvings narrow the quality range enough that the result lands close to the limit. On a large, noisy 2400 by 3200 photo we tried, the results were 19,921 bytes for a 20 KB limit, 48,258 for 50 KB and 99,765 for 100 KB: always under, and within a few percent.

When quality is not enough#

A 4 MB photo cannot reach 50 KB by lowering quality alone without turning into mush. Pixels are the other lever. So the search has a ladder of sizes, from full size down to 15%, and two rules:

1. First, keep quality at 50% or better and step down the ladder until a size fits.
2. Only if nothing fits that way, allow quality as low as 10%.

for (const low of [0.5, 0.1]) {
  for (const scale of SCALES) { // 1, 0.9, 0.8 ... 0.15
    const hit = await bestQuality(encode, scale, maxBytes, low)
    if (hit) return { ...hit, fits: true }
  }
}

The order matters. A slightly smaller picture at decent quality almost always looks better than a full-size picture crushed into blocks, and forms rarely care about the pixel size, only the file size.

Keep the search separate from the browser#

The search never touches a canvas. It takes an encode(scale, quality) function that returns a Blob, so the same code runs in a test with a fake encoder whose size grows with pixels and quality:

const fake = (fullBytes) => async (scale, quality) =>
  new Blob([new Uint8Array(Math.round(fullBytes * scale * scale * (0.05 + quality)))])

With that we test the behaviour we care about: a file that already fits is left alone at high quality; quality is lowered before pixels are; a huge image shrinks but keeps quality at 50% or better; the result is never over the limit when it says it fits; and when nothing can fit, it says so rather than pretending.

Details that bit us#

• Kilobytes. Some systems count 1 KB as 1000 bytes and some as 1024. A file of 51,200 bytes is "50 KB" to one and 51.2 KB to the other, so a form using the first rule would reject it. We count 1000 bytes per KB, so the file passes either way.
• Transparent PNGs. JPEG has no transparency, so the picture is drawn onto white first, otherwise transparent areas turn black.
• Format support. canvas.toBlob quietly returns PNG if the browser cannot save the format you asked for. We check the returned type and show a clear message instead.
• Browsers differ. Each browser has its own JPEG encoder, so the same quality gives slightly different sizes. That is fine, because the search measures the real size each time rather than predicting it.
• Privacy. The whole thing runs in your browser. The photo is never sent anywhere, and saved copies do not carry camera details like location.

What it cannot do#

If a form wants an exact pixel size (say 200 by 230) as well as a file size, set the pixels first with an image resizer and then reduce the size. And a form that wants a minimum size as well as a maximum needs a check on the result: we make the file as large as fits, but a small original cannot be made bigger.

What happens to your file#

1. You pick a file. Your browser reads it into memory on your device.
2. The page's own code works on it there. PDFs are edited with a library called pdf-lib, and pages are drawn with pdf.js, the PDF reader that is built into Firefox. Photos are resized and compressed with the browser's built-in drawing surface, the canvas.
3. The result is made in memory too. When you press Download, the browser saves it from there to your device.

Nothing in that path needs a server, so we did not build one.

How to check it yourself#

Open your browser's developer tools (F12 on most computers) and go to the Network tab. Then use a tool on a file.

• You will see requests for the page, its scripts and its fonts, all from the Tools site itself.
• You will not see a request that carries your file or its contents. Nothing is uploaded when you press the button.

The code is written so that the only fetch calls in the site read a QR code image the page has just made on your device, to save it as a file.

What we do see#

Tools is delivered by Google Firebase Hosting. Like any web host, it handles standard request details such as your IP address, the time, the page you asked for and your browser type, and may keep them in routine logs. We do not use these logs to identify anyone. We add no analytics, no ads and no tracking tools of our own, and the site sets no cookies. Your theme choice and similar small settings, where used, stay in your browser.

The limits of working on your device#

Doing the work locally is a trade, and some of the costs are yours:

• Memory. Big files need a lot of memory. A very large photo, over about 50 megapixels, can fail on an older phone.
• Page limits. "Pages as pictures" in Compress PDF works up to 100 pages at a time. Split large files first.
• Compress PDF has two modes. "Keep text" repacks the file and often saves little. "Pages as pictures" can save a lot, but text can no longer be selected or searched, and links and form fields stop working. The tool says so and shows the new size before you download.
• Password-protected PDFs cannot be opened. Remove the password first.
• Photos lose camera details. Resized and compressed photos are redrawn, so details such as the location are not copied into the new file.

Why we built it this way#

Part of it is privacy: the safest place for a file is the one you already control. Part of it is cost. With no server handling your files, an idle tool costs almost nothing, and that is what lets us keep it free without ads. The next post covers that: why Shridha has no ads.

Do not write down offsets#

The first rule is to never store "India is UTC+5:30" or "New York is UTC-5". New York is UTC-5 in winter and UTC-4 in summer, and the switch dates move around by country and by year. A table of offsets goes wrong the day a government changes its rules.

Browsers already carry the full time zone database, and Intl.DateTimeFormat can tell you the wall-clock time in any zone at any moment. From that you can work out the offset for that exact moment:

/** Minutes that `zone` is ahead of UTC at the moment `ms`. */
function offsetMinutes(zone, ms) {
  const p = wallClock(zone, ms) // year, month, day, hour, minute, second in that zone
  const asUtc = Date.UTC(p.y, p.m - 1, p.d, p.h, p.min, p.sec)
  return Math.round((asUtc - Math.floor(ms / 1000) * 1000) / 60000)
}

wallClock is a small helper over Intl.DateTimeFormat(...).formatToParts(ms). The browser does all the daylight saving maths, and the code never mentions a date when clocks change.

From "9:00 on 4 November in Kolkata" to a moment#

The reverse direction is trickier. A person types a local time, and you need the exact moment it means. The offset depends on the moment, which is what you are trying to find. The fix is to guess, then correct:

function zonedToInstant(zone, y, m, d, h, min) {
  const guess = Date.UTC(y, m - 1, d, h, min)
  const first = guess - offsetMinutes(zone, guess) * 60000
  return guess - offsetMinutes(zone, first) * 60000
}

The first pass uses the offset at the wrong moment, and the second pass corrects it using the offset at the first answer. Two passes are enough for real zones. We test it by round trip: convert a local time to a moment and back, in zones like Kolkata, Kathmandu (UTC+5:45), New York, London, Sydney and Auckland, and check we get the same time.

Two clock times are special. When clocks go forward, an hour does not exist (2:30 on that morning). When they go back, an hour happens twice. The code above gives a real moment in both cases: for the repeated hour it returns the first of the two, and for the missing time it returns the moment that reads an hour earlier on the clock (so 2:30 on a spring-forward morning in New York becomes 1:30). That is consistent and never crashes, but it is a choice, and a more careful app would warn the person when they pick one of these times.

The bug: a day is not always 24 hours#

Our first version of the timeline made 24 hourly slots starting at midnight in the first person's zone. That is wrong on two days a year in most places:

• When clocks go forward, the day has 23 hours, so 24 slots spill into the next day.
• When clocks go back, the day has 25 hours, so 24 slots miss the last hour.

We noticed because 1 November 2026 was a day when US clocks went back. The fix is to build the day from one local midnight to the next, and count the slots in between:

const start = zonedToInstant(zone, y, m, d, 0, 0)
const end = zonedToInstant(zone, nextY, nextM, nextD, 0, 0)
const count = Math.round((end - start) / SLOT) // SLOT is 30 minutes

With half-hour slots this gives 48 on a normal day, 46 on a 23-hour day and 50 on a 25-hour day. Lord Howe Island in Australia changes clocks by only 30 minutes, so its day has 47 slots. Our tests check all of these, and also that each day starts and ends at local midnight.

Two countries, two change dates#

The other trap is that neighbours do not switch on the same day. In 2026, the UK moved its clocks back on 25 October and the US on 1 November. For that week, London and New York are 4 hours apart instead of the usual 5. The same happens in March, when the US changes before the UK.

So a team in London and New York has the same shared working window most of the year, but a different one for a week:

A planner that checks only "today" will give the wrong answer for a meeting booked on the other side of a change. That is why Timezone Buddy works on a chosen date, and warns when anyone's clocks change within a few days of it.

Share a moment, not a clock time#

When you send someone the meeting time, send the moment and let their device show it locally. In the calendar invite we write the start as a UTC time (DTSTART:20261104T093000Z), so Google Calendar, Apple Calendar and Outlook each show it correctly for the person who opens it, including after clocks change.

What we did not solve#

A few places change their clocks at midnight, so the first midnight of the day can be skipped. We pick the first valid time, but we have not tested those zones in a browser. And the planner trusts the browser's time zone database, so a device with an out-of-date system will be wrong about a recent rule change.

What ads would need#

An ad on a page is not just a picture. It usually brings extra scripts from other companies, measurement of what you click, and a profile of who you are so the ad can be matched to you. For a tool where you paste a salary, open an invoice or upload a scan, that is the wrong trade. The more private the job, the worse it fits.

Ads also slow pages down and push the useful part around. We would rather the page do its one job and get out of the way.

What keeps the apps free instead#

The answer is mostly cost. If an app is cheap enough to run, it does not need to earn money.

• Most of our apps are static sites. They are files on a host, and many of them do their work in your browser. There is no server running for each visitor.
• Where an app does need a server, for example to hold a one-time secret or a short link, we use pay-per-use services. An app that nobody is using costs close to nothing.
• We do not keep a fixed monthly bill for each app. That rule decides what we build: if an idea needs something always running, we look for a different way to do it or leave it out.

Shridha is also an engineering studio, and these apps are built to need very little to keep going. That is a design choice, not an accident.

What it rules out#

Saying no to ads and fixed costs means saying no to some ideas. Anything that needs heavy servers all day, such as processing video for you, is hard to offer free. We would rather say so than quietly add a limit later. Bosswala, which does run on servers for staff attendance and shared leads, has a small fee for that reason.

What it means for you#

• No ads and no tracking tools in the free apps.
• No need to make an account to do a simple job.
• Where an app offers a sign-in, it is optional.

You can see the full list in the apps catalog. For how the file tools keep your data on your own device, read how Tools works on your files without uploading them.

Most people who use software for ordinary jobs have met the same three problems. A free plan gets smaller every year. Ads and trackers creep in. Or a tool that should take ten seconds asks you to make an account first.

Our free apps are an answer to that. They are small, useful, free to use, private by default and have no ads. They are for developers, builders and small business owners, and for small businesses in India first, because that is where we saw the biggest gap between what people need and what is free.

What we have built so far#

The full list lives in the Shridha apps catalog. A few examples:

• Tools: loan, tax and GST calculators, image and PDF tools, QR codes and developer utilities, all running in your browser.
• Invoice Maker: GST invoices, quotes and bills of supply as PDFs, with your details kept on your own device.
• Panchang: tithi, nakshatra and festivals for Indian cities, in Hindi and English.
• typeflow: a typing test that shows which keys slowed you down.
• Gupt: send a password or secret that opens only once.
• Smaran Ghanti: a mala counter and reminders for daily naam jap.

The rules we build by#

Free stays free. If an app is free today, we do not move its core features behind a paywall later. We would rather build fewer things than break that.

Private by default. Where we can, the work happens in your browser, so your files and numbers never reach us. No ads, and no tracking tools.

Accounts are optional. An account is offered only when it gives you something real, such as saving your results, and the app works without one.

Cheap to run, so the promise is affordable. We use static hosting and pay-per-use services, so an app that nobody is using costs close to nothing. That is what makes the first rule possible. We wrote more about this in why Shridha has no ads.

One exception, stated plainly. Bosswala, our attendance and leads app for Indian shops, charges a small fee to cover what it costs to run. It is listed in the catalog with that difference clear.

What this blog is for#

It covers the studio and the apps. Two kinds of post. The journey: what we decided, what we dropped, and why. And docs: how things are built and how they work, written for people who want to check our claims rather than trust them. The next post, how Tools works on your files without uploading them, is the first of those.

If there is an everyday job you wish had a free, private tool, tell us.