DEV Community: Saurabh Sharma

I built a GIF compressor that runs 100% in your browser (because Discord's file limits are the worst)

Saurabh Sharma — Thu, 27 Aug 2026 08:33:26 +0000

If you've ever tried to upload a GIF as a Discord emoji, you know the drill. Discord wants it under 256KB, your export is 4MB, and now you're bouncing between three different "free" online converters. One of them gates batch processing. Another caps how many files you can run per day. Another quietly uploads your file to a server you never agreed to.

I got tired of that loop, so I built CompressGIFs. It's a small GIF toolkit that runs entirely in your browser. No upload, no account, no daily cap.

Here's what it does and why I built it this way.

The actual problem

"Compress a GIF" sounds like a solved problem. It isn't, once you look at what people actually need:

Discord emoji: 256KB, 128×128
Discord stickers: their own size and format quirks
Slack emoji, WhatsApp stickers, Telegram stickers: all different limits
And the universal one: "just make this smaller, I don't care about the settings, I just need it to work"

Every tool I tried made me guess. Drag a quality slider, export, check the file size, repeat until it's small enough. That's a bad experience for something that should be simple. I already know my target size. The tool should just get me there.

What's different here

1. You tell it the target size and it finds the settings for you.

Instead of a lossy quality slider, you type "under 256KB" or pick a Discord, Slack, WhatsApp, or Telegram preset. The tool then runs a binary search across compression parameters until the output lands under your target:

Binary search gifsicle's --lossy value (1 to 200)
Still too big? Binary search --colors (256 down to a floor)
Still too big? Fall back to proportional downscaling, step by step

This runs inside a Web Worker so the tab doesn't freeze while it's working. Some of these searches take a few seconds on bigger files, and you actually see live progress instead of a frozen screen.

2. It's genuinely client-side.

The compression engine is gifsicle compiled to WASM, running right in your browser. Your GIF never touches a server. That's not just a privacy checkbox I'm ticking. It's also the reason the next point is even possible.

3. Batch processing isn't a paywall.

I checked what the big converters actually offer on their free tiers. One well-known one caps you at 10 conversions a day and a 5-file batch limit. Batch processing is literally their paid upsell. That makes sense when you're paying for server compute per file. It doesn't make sense here, because there's no server doing the work. Your own machine is. So batch is just unlimited. Drop in a folder of 40 GIFs, walk away, come back to 40 compressed files.

4. A compliance checker, not just a compressor.

This is honestly the tool I wanted most for myself. Upload a GIF, pick "Discord Sticker" or "Slack Emoji," and get a clear pass or fail on size, dimensions, and format all together, with a specific note on what to fix if it fails. If you moderate a Discord server, this is the kind of thing you pin in your assets channel so people stop asking why their upload keeps getting rejected.

Why not just build "one more compress gif page"

Before writing any code, I looked at who actually ranks for these terms. The space is dominated by a 13 year old incumbent with hundreds of interlinked tool pages and real domain authority. That's not something a single new landing page beats just by looking nicer. So instead of chasing the generic "compress gif" term head on, I scoped this narrower and deeper. A full GIF workflow: compress, resize, convert, and validate against platform limits, with the Discord specific tools front and center, since that's the highest intent, most underserved corner of this whole space right now.

Stack, if you're curious

Astro (static, zero backend)
gifsicle-wasm-browser for the actual compression, lazy loaded so it doesn't bloat the initial page weight
Web Workers for the target size search loop
Cloudflare Pages for hosting

No database, no API, no account system. Just static files and WASM running on your CPU.

Try it

compressgifs.com. Free, no signup, nothing leaves your browser.

If you run a Discord server, the Discord compliance checker is worth a look on its own. It's the tool I wish had existed before I spent an entire afternoon manually re-exporting stickers at four different sizes.

Would genuinely love feedback from this crowd, especially if you hit an edge case where the target size search doesn't converge. That's the part I'm most paranoid about getting wrong.

What I Learned Building a Payroll Calculator Site Solo (Not Truly Solo 😅)

Saurabh Sharma — Fri, 14 Aug 2026 07:54:02 +0000

PayTimeHub started as one page - a paycheck withholding calculator - because I couldn't find one online that didn't bury the number under three popups and an email gate. It's since grown into a small family of calculators: paycheck withholding by state, a raise calculator, hourly-to-salary conversion, hours-to-decimal timesheet conversion, and time-and-a-half overtime. Nothing behind a signup, nothing sent to a server. A few things stood out along the way that I didn't expect going in.

The tax logic is the actual product

I assumed the hard part would be the frontend. It wasn't. Federal withholding is a set of published brackets, but state withholding is fifty different rulebooks, several of which don't tax income at all, some of which have their own standard deduction schedules, and a couple that change their brackets more often than you'd think reasonable for a tax table. Getting [state]-paycheck-calculator right per state meant the actual engineering effort lives in a tax engine, not in a component tree. The UI took a weekend. The tax logic is still the thing I go back and double-check.

The lesson: for a "calculator" site, the calculator is the product. Everything else - layout, copy, SEO - is packaging around a number that has to be correct, because a wrong number here isn't a cosmetic bug, it's a wrong paycheck estimate someone might actually plan around.

Floating-point math will find you eventually

Money math in JavaScript looks fine until it doesn't. 0.1 + 0.2 not equaling 0.3 is the famous example, but the version that actually bit me was subtler: a raise calculation that produced $53,999.999999999996 instead of a clean $54,000 on one specific input, not because of an obviously bad float, but because the multiplication itself introduced error just below a rounding boundary. I wrote about that one separately, but the broader takeaway was that every calculator that touches money needs to funnel through the exact same rounding function, or you end up with five slightly different .toFixed(2) calls that quietly disagree with each other on the edges.

Static-first is a feature, not a shortcut

Astro was the right call, but not for the reason I expected going in. I picked it for the build output - static pages, minimal JS, fast Lighthouse scores. What turned out to matter more is that "no server, no data leaves the browser" isn't just a privacy pitch, it removes an entire category of things I don't have to build: no auth, no database, no rate limiting, no GDPR data-handling story. The calculators run entirely client-side. That constraint made the whole project smaller in a good way - there's less surface area for something to go wrong, and less to maintain six months from now.

Dynamic routes make "fifty states" tractable

Before I set up [state]-paycheck-calculator and [value]-salary-to-hourly as dynamic routes, I was mentally treating "add all 50 states" as fifty separate pages to hand-write. That's the wrong mental model for this kind of site. One template plus a data file per state is the actual shape of the problem, and it's the difference between a task that takes a weekend and one that never gets finished because it feels too big to start.

Shipping something narrow beats shipping something broad

Early on I was tempted to build a general "financial calculator suite" - retirement, mortgage, budgeting, the works. I'm glad I didn't. Payroll and pay math is a coherent enough niche that the calculators reinforce each other: someone converting hourly to salary is plausibly also the kind of person who wants to know their overtime rate or their raise in real terms. A broader suite would have diluted that, and I'd have shipped ten shallow tools instead of five that actually do their one job well.

What's next

More state-specific accuracy passes, and probably a couple more calculators in the same vein - the goal isn't to cover every financial calculation that exists, just to keep doing pay and payroll math well. If you're curious, the whole thing is live at paytimehub.com.

The rounding bug that almost shipped in a payroll calculator

Saurabh Sharma — Fri, 14 Aug 2026 07:47:02 +0000

I've been building PayTimeHub, a set of free payroll and pay calculators - paycheck withholding, raise calculator, hours-to-decimal, time and a half. Money math looks trivial until you actually ship it, and one bug almost got through that's worth writing up.

The setup

Every calculator on the site takes a dollar amount, does some arithmetic on it, and shows the result back to the user. A raise calculator multiplies a salary by a percentage. An overtime calculator multiplies an hourly rate by 1.5. Simple stuff, until you remember that JavaScript does floating-point math.

Try this in a console:

0.1 + 0.2
// 0.30000000000000004

Now imagine that showing up on a page that's supposed to tell someone their new salary. A $52,000 salary with a 3.85% raise should read as a clean $54,000. Depending on how you chain the multiplication and division, you can end up with something like $53,999.999999999996, which then gets formatted and displayed as a genuinely wrong number - or worse, rounds inconsistently between two calculators that are supposed to agree with each other.

The fix

Nothing exotic, just a single shared rounding function that every calculator on the site routes its output through before display:

export function roundCurrency(amount: number): number {
  return Math.round((amount + Number.EPSILON) * 100) / 100;
}

The Number.EPSILON nudge matters more than it looks like it should. Without it, plain Math.round(amount * 100) / 100 still misfires on specific inputs, because the multiplication itself can introduce a floating-point error just below a rounding boundary, so a value that should round up rounds down instead. Adding the smallest possible float before rounding pushes those edge cases back onto the correct side without changing any value that wasn't on the boundary to begin with.

Why it's worth writing down

The interesting part isn't the fix - it's that this exact class of bug is invisible in casual testing. Round numbers like $50,000 and 5% never trigger it. It shows up on the specific combinations that don't divide cleanly, the ones a user actually types in, not the ones a developer thinks to test.

Every money-handling calculator on the site now funnels through one rounding function instead of each one doing its own .toFixed(2) inline. Partly for consistency, but mostly so this bug only had one place it could hide.

If you're building anything that does arithmetic on money in JavaScript and displays the result, it's worth checking whether you have one rounding function or five slightly different ones scattered across the codebase. It's an easy thing to get right once, and an easy thing to get subtly wrong five separate times.

Built with Astro, if anyone's curious about the stack. The site itself is at paytimehub.com if you want to see it in action — specifically the pay raise calculator, where this first came up.

🧭 React Router Crash Course (Beginner Friendly)

Saurabh Sharma — Thu, 04 Dec 2025 08:29:45 +0000

Learn what routing is, why it matters in React, and how to set it up step-by-step — with a mini React demo project.

🧐 What Is Routing in React?

So, what the heck is routing?

In simple terms, routing controls what your app shows when a user navigates to different pages.

That’s it! When you click on something like “About” or “Contact,” routing decides which component gets displayed on the screen.

🌐 How Traditional Routing Works

Before SPAs (Single Page Applications), websites used normal HTML navigation with the <a> tag:

<a href="/about">Go to About Page</a>

Every time you clicked on that link, the browser reloaded the page from scratch. That means your app reset, and the DOM (Document Object Model) re-rendered completely — not very efficient!

⚛️ React: The Power of Single Page Applications (SPA)

React builds Single Page Applications, where everything runs inside one main HTML file: index.html.

When navigation happens, React simply replaces parts of the UI dynamically, rather than reloading the entire page.

But to make that navigation magic happen, React needs help — that’s where react-router-dom comes in.

📦 Installing React Router

React itself doesn’t handle routing, so you’ll need to install a library for it. The most popular one is react-router-dom.

Use your package manager of choice:

npm install react-router-dom

Or:

pnpm add react-router-dom

🏗️ Step 1: Setup `BrowserRouter`

After installing, wrap your whole app with BrowserRouter.

This enables React Router throughout your application.

// main.jsx
import React from 'react'
import ReactDOM from 'react-dom/client'
import { BrowserRouter } from 'react-router-dom'
import App from './App.jsx'

ReactDOM.createRoot(document.getElementById('root')).render(
  <BrowserRouter>
    <App />
  </BrowserRouter>
)

That’s your basic setup! Without this step, your app won’t understand routes.

🗺️ Step 2: Define Routes with `<Routes>` and `<Route>`

Now it’s time to tell React what to show on each URL path.

// App.jsx
import { Routes, Route } from 'react-router-dom'
import Home from './pages/Home'
import About from './pages/About'
import Contact from './pages/Contact'
import NotFound from './pages/NotFound'

function App() {
  return (
    <Routes>
      <Route path="/" element={<Home />} />
      <Route path="/about" element={<About />} />
      <Route path="/contact" element={<Contact />} />
      {/* Catch all unknown routes */}
      <Route path="*" element={<NotFound />} />
    </Routes>
  )
}

export default App

/ → Home Page
/about → About Page
/contact → Contact Page
* → Not Found / 404 Page

🔗 Step 3: Create Navigation with `Link` and `NavLink`

Instead of using normal <a> tags, React gives us special components: Link and NavLink.

These navigate between pages without reloading the app.

// Navbar.jsx
import { Link, NavLink } from 'react-router-dom'

function Navbar() {
  return (
    <nav>
      <Link to="/">Home</Link>
      <Link to="/about">About</Link>
      <NavLink
        to="/contact"
        className={({ isActive }) => (isActive ? 'active' : '')}
      >
        Contact
      </NavLink>
    </nav>
  )
}

export default Navbar

✅ Link: Basic navigation (no reload).

✅ NavLink: Same as Link, but automatically adds an “active” class to the current route — perfect for styling active menu items.

🧩 Step 4: Nested Routes and `<Outlet />`

Sometimes you’ll want routes inside routes, like for a dashboard that contains multiple sections (e.g., profile, settings).

That’s where nested routes come in — and the <Outlet /> component helps render them in the right place.

// App.jsx
<Routes>
  <Route path="/" element={<Home />} />
  <Route path="/dashboard" element={<Dashboard />}>
    <Route path="profile" element={<Profile />} />
    <Route path="settings" element={<Settings />} />
  </Route>
</Routes>

Inside Dashboard.jsx:

// Dashboard.jsx
import { Outlet } from 'react-router-dom'

function Dashboard() {
  return (
    <div>
      <h2>Dashboard</h2>
      {/* Child routes will render here */}
      <Outlet />
    </div>
  )
}

export default Dashboard

Now, when visiting /dashboard/profile, React automatically renders the Profile component inside the Dashboard layout!

🚀 Mini React Demo Project: "My First Routed App"

Let’s put it all together into a working mini project.

File Structure:

src/
  ├── main.jsx
  ├── App.jsx
  ├── components/
  │     └── Navbar.jsx
  ├── pages/
  │     ├── Home.jsx
  │     ├── About.jsx
  │     ├── Contact.jsx
  │     └── NotFound.jsx

Example Pages:

// pages/Home.jsx
function Home() {
  return <h1>Welcome to My React App!</h1>
}
export default Home

// pages/About.jsx
function About() {
  return <h1>About This Project</h1>
}
export default About

// pages/Contact.jsx
function Contact() {
  return <h1>Contact Me Anytime!</h1>
}
export default Contact

// pages/NotFound.jsx
function NotFound() {
  return <h1>404 — Page Not Found</h1>
}
export default NotFound

Add the Navbar:

// App.jsx
import Navbar from './components/Navbar'

function App() {
  return (
    <>
      <Navbar />
      <Routes>
        <Route path="/" element={<Home />} />
        <Route path="/about" element={<About />} />
        <Route path="/contact" element={<Contact />} />
        <Route path="*" element={<NotFound />} />
      </Routes>
    </>
  )
}

Now you’ve got a complete, simple React app with modern routing — no page reloads, smooth navigation, and clean URLs.

⚙️ Bonus: Things to Explore Next

React Router Docs — Learn about advanced features like useNavigate, loaders, lazy loading, and route transitions.
Try adding a 404 redirect or a Protected Route for authenticated sections.
Use NavLink styling to highlight the active page.

🏁 Wrapping Up

You just learned how to set up React Router from scratch — including how to install it, define routes, use navigation components, and manage nested routes cleanly.

Now, whenever you start a new React project, you’ll know exactly how to make it multi-page while keeping it fast and smooth.

Keep building! 💪