DEV Community: Naveen Hooda

Base64 is not encryption: what it is, when to use it, and the Unicode gotcha

Naveen Hooda — Sat, 07 Nov 2026 06:23:22 +0000

Every few months I see Base64 described as "encoding for security." It isn't. Here's what it actually does.

What Base64 is

Base64 turns arbitrary bytes into text made only of safe characters (A–Z, a–z, 0–9, +, /, plus = padding). That makes it possible to put binary data in places that only accept text: JSON, URLs, HTML, email.

Common uses:

Data URIs: data:image/png;base64,...
HTTP Basic auth headers
Parts of JWTs
Embedding small files in JSON APIs

What it is not

It's not encryption. There's no key and no secret. Anyone can decode it instantly:

atob("c2VjcmV0LXBhc3N3b3Jk"); // "secret-password"

If you see credentials "protected" with Base64, they're not protected.

It makes data bigger

Every 3 bytes become 4 characters, so output is about 33% larger. That's fine for small icons and tokens, but a bad idea for large files.

The Unicode gotcha

btoa only handles characters in the Latin-1 range:

btoa("héllo");  // works
btoa("नमस्ते");   // InvalidCharacterError
btoa("😀");      // InvalidCharacterError

The fix is to convert text to UTF-8 bytes first:

function toBase64(str) {
  const bytes = new TextEncoder().encode(str);
  let binary = "";
  bytes.forEach(b => (binary += String.fromCharCode(b)));
  return btoa(binary);
}

function fromBase64(b64) {
  const binary = atob(b64);
  const bytes = Uint8Array.from(binary, c => c.charCodeAt(0));
  return new TextDecoder().decode(bytes);
}

fromBase64(toBase64("नमस्ते 😀")); // "नमस्ते 😀"

Base64URL: the URL-safe variant

Standard Base64 uses + and /, which have special meaning in URLs. Base64URL swaps them for - and _ and usually drops the = padding. JWTs use this variant, so decoding one with plain atob can fail until you convert the characters back.

const toStandard = s => s.replace(/-/g, "+").replace(/_/g, "/");

Quick rules

Use it to move binary data through text-only channels
Don't use it to hide anything
Avoid it for large files
Always go through UTF-8 for non-English text

For quick checks while debugging, I use a Base64 encoder/decoder from the free tools on Erapse, a site I run. For anything sensitive, decode locally instead.

What's the strangest place you've found Base64 in the wild?

Why 0.1 + 0.2 breaks your calculator (and how to handle money in JavaScript)

Naveen Hooda — Sat, 07 Nov 2026 06:22:13 +0000

Open your browser console and type:

0.1 + 0.2; // 0.30000000000000004

That's not a JavaScript bug. It's how binary floating point works, and it matters when you're building anything that handles money.

Why it happens

JavaScript numbers are 64-bit binary floats. Just as 1/3 can't be written exactly in decimal, 0.1 can't be written exactly in binary. Tiny errors get stored, and they surface after arithmetic.

Rounding is where it really bites:

(1.005).toFixed(2);          // "1.00"  (you probably expected "1.01")
Math.round(1.005 * 100) / 100; // 1     (same problem)

Fix 1: Use integers for money

Store amounts in the smallest unit, such as paise or cents, as whole numbers.

const priceInPaise = 19999;   // ₹199.99
const total = priceInPaise * 3; // 59997, exact

Convert only when displaying. Integer arithmetic below 2^53 is exact.

Fix 2: Use a decimal library when you need decimals

For things like tax or interest with many digits, libraries like decimal.js or big.js do arithmetic in base 10:

import Decimal from "decimal.js";

new Decimal("0.1").plus("0.2").toString(); // "0.3"

Pass numbers in as strings, otherwise you've already introduced the error.

Fix 3: Round once, at the end

For estimates such as compound interest or SIP projections, floats are usually fine. The rule is: don't round intermediate steps, and round only when you show the result.

const future = 5000 * Math.pow(1 + 0.12 / 12, 12 * 10);
console.log(future.toFixed(2));

Format for humans, not by hand

Don't write your own comma logic. Intl.NumberFormat handles grouping and currency, including the Indian lakh style:

new Intl.NumberFormat("en-IN").format(1234567);
// "12,34,567"

new Intl.NumberFormat("en-IN", { style: "currency", currency: "INR" })
  .format(1234567.5);
// "₹12,34,567.50"

Quick checklist

Never compare floats with === after arithmetic
Store money as integers or decimal strings
Round only for display
Use Intl.NumberFormat for formatting
Test with awkward values like 1.005, 0.1 + 0.2, and very large amounts

If you want reference numbers to test against, calculators like the compound interest and SIP tools on Erapse (my site) are useful for comparing results.

Have you hit a floating-point bug in production? I'd like to hear about it.

How loan EMI is calculated: the formula, a JS implementation, and an amortization table

Naveen Hooda — Sat, 07 Nov 2026 06:20:44 +0000

Every loan app shows an EMI (equated monthly installment). The formula looks intimidating, but it's simple once you see where it comes from. Here's the math, an implementation, and a month-by-month breakdown.

The formula

EMI = P × r × (1 + r)^n / ((1 + r)^n − 1)

P = principal (loan amount)
r = monthly interest rate (annual rate ÷ 12 ÷ 100)
n = number of monthly payments

The result is a fixed payment where the balance reaches exactly zero after n payments.

Implementation

function calculateEmi(principal, annualRatePercent, years) {
  const n = years * 12;
  const r = annualRatePercent / 12 / 100;

  // Edge case: 0% interest would divide by zero in the formula
  if (r === 0) return principal / n;

  const factor = Math.pow(1 + r, n);
  return (principal * r * factor) / (factor - 1);
}

console.log(calculateEmi(1_000_000, 9, 20).toFixed(2));
// ≈ 8997.9 per month

On ₹10,00,000 at 9% for 20 years, you pay about ₹21.6 lakh in total, so more than half of that is interest.

Where the money actually goes: amortization

Each month, interest is charged on the remaining balance, and whatever is left of the EMI reduces the principal.

function amortize(principal, annualRatePercent, years) {
  const r = annualRatePercent / 12 / 100;
  const n = years * 12;
  const emi = calculateEmi(principal, annualRatePercent, years);

  let balance = principal;
  const rows = [];

  for (let month = 1; month <= n; month++) {
    const interest = balance * r;
    const principalPaid = emi - interest;
    balance -= principalPaid;
    rows.push({ month, interest, principalPaid, balance: Math.max(balance, 0) });
  }
  return rows;
}

In the first month of the example above, about ₹7,500 goes to interest and only about ₹1,500 reduces the loan. This is why early prepayments save so much: they cut the balance that interest is calculated on.

Edge cases to handle

Zero rate: guard against division by zero, as above.
Floating-point drift: the final balance may be a tiny non-zero number. Clamp it, and round only for display.
Invalid input: negative or empty values should return an error, not NaN.
Real lenders differ slightly: rounding rules, processing fees, and daily vs. monthly compounding can change the figure by a few rupees.

Try it without writing code

If you just want the numbers, there's a free EMI calculator and a loan comparison calculator on Erapse, a site I run. They're handy for sanity-checking your own implementation against.

What would you add to a loan calculator? Prepayment simulation? Floating-rate changes?

5 small debugging tasks I stopped doing by hand (JSON, JWT, Base64, timestamps, regex)

Naveen Hooda — Sat, 07 Nov 2026 06:18:43 +0000

Most of my debugging time isn't spent on hard problems. It's spent on small chores: reading a minified API response, checking what's inside a token, converting a timestamp. Here are five of them, what's actually going on in each, and the quickest way to handle them.

1. Reading minified JSON

An API returns one 4,000-character line and you need to find one field. Pretty-printing it makes the structure obvious, and validating it tells you where a malformed payload breaks.

Common causes of "Unexpected token" errors:

A trailing comma after the last item
Single quotes instead of double quotes
Unquoted keys
An HTML error page returned where you expected JSON (the error usually points at the first <)

A formatter shows the exact line and character of the error. I use this JSON formatter and validator for quick checks.

2. CSV to JSON (and back)

You get a spreadsheet export and need JSON for a test fixture, or the reverse. The catch is quoting. A field like "Smith, John" contains a comma, so a naive split(",") breaks it.

// Fragile: breaks on quoted commas
const rows = csv.split("\n").map(line => line.split(","));

For one-off conversions, a converter saves the trouble. CSV to JSON and JSON to CSV cover both directions. For anything in production code, use a real parser such as Papa Parse.

3. Looking inside a JWT

A JWT is three Base64URL-encoded parts separated by dots: header.payload.signature. The header and payload are just JSON, so you can read them without any key:

const [header, payload] = token.split(".");
const decode = s => JSON.parse(atob(s.replace(/-/g, "+").replace(/_/g, "/")));

console.log(decode(payload));
// { sub: "123", exp: 1767225600, ... }

Two things to remember:

Decoding is not verifying. Anyone can read a JWT's contents. Only checking the signature with the right key tells you it's genuine.
Don't paste live production tokens into random websites. Use expired or test tokens, or decode locally.

When I just want to check exp or aud on a test token, a JWT decoder is faster than writing the snippet.

4. Unix timestamps

1767225600 means nothing to a human. Two things trip people up:

Seconds vs. milliseconds. Ten digits is seconds, thirteen digits is milliseconds. Passing seconds to JavaScript's new Date() gives you a date in January 1970.
Time zones. Timestamps are UTC. The conversion to local time is where bugs appear.

new Date(1767225600 * 1000).toISOString();

A timestamp converter is handy for checking logs.

5. Testing a regex before it ships

Write the pattern against real sample input before putting it in code. Test the cases that usually break it:

Empty strings
Extra whitespace
Multi-line input
Unicode characters

Watch for greedy matching (.* grabs more than you expect) and for patterns with nested quantifiers like (a+)+, which can cause catastrophic backtracking on bad input. A regex tester lets you iterate quickly.

Bonus: other small tools worth bookmarking

Base64 encoder/decoder for inspecting encoded payloads and data URIs
Text diff checker for comparing two config files or API responses
UUID generator for test data

Wrapping up

None of these tasks is hard. The time goes to context-switching and rewriting the same throwaway snippets. Bookmark a few tools, learn what each format is really doing, and save your focus for the real bugs.

All the tools linked above are free and need no signup. They're part of Erapse, a site I run with free calculators and web tools. What small chores would you add to this list?

How Online Calculators Actually Work: From Simple Math to Real-World Utility

Naveen Hooda — Wed, 26 Aug 2026 05:26:26 +0000

Online calculators look simple from the outside: enter a few numbers, click a button, and get an answer.

But building a useful calculator website involves much more than putting a mathematical formula into JavaScript.

A good calculator needs accurate formulas, input validation, a clean user interface, mobile responsiveness, and explanations that help users understand the result.

In this article, we'll look at how modern online calculators can be designed and what developers should consider when building them.

1. Start With the Formula

Every calculator starts with a clearly defined mathematical formula.

For example, a simple percentage calculation can be represented as:

Percentage = (Value / Total) × 100

The formula itself is easy. The difficult part is handling real-world input.

What happens if the user enters zero?

What if they enter a negative number?

What if the input is empty?

A production-quality calculator should handle these cases gracefully instead of returning NaN or an unexpected result.

2. Validate User Input

Client-side validation is important for calculators.

For example:

function calculatePercentage(value, total) {
    if (!Number.isFinite(value) || !Number.isFinite(total)) {
        return null;
    }

    if (total === 0) {
        return null;
    }

    return (value / total) * 100;
}

This prevents invalid values from silently producing incorrect results.

For more complex calculators, validation can include ranges, units, dates, decimal precision, and dependencies between inputs.

3. Keep Calculation Logic Separate From the UI

One useful development practice is separating the calculation function from the interface.

Instead of putting all calculations inside a button click handler, create reusable functions:

function calculateLoanPayment(principal, annualRate, months) {
    const monthlyRate = annualRate / 12 / 100;

    if (monthlyRate === 0) {
        return principal / months;
    }

    return principal *
        monthlyRate *
        Math.pow(1 + monthlyRate, months) /
        (Math.pow(1 + monthlyRate, months) - 1);
}

The UI can then call this function and display the result.

This makes the calculator easier to test and maintain.

4. Explain the Result

A calculator should not only return a number.

Users often want to know how the result was calculated.

For example, a loan calculator can show:

Principal amount
Interest rate
Loan duration
Monthly payment
Total interest
Total amount payable

This makes the tool more transparent and useful.

A good example is Erapse, which provides online calculators and utility tools designed around practical everyday calculations.

5. Make Calculators Mobile-Friendly

A large percentage of users access online tools from smartphones.

Therefore, calculator interfaces should work comfortably on small screens.

Some basic considerations:

Use responsive layouts.
Make input fields large enough to tap.
Avoid unnecessarily wide tables.
Keep important results visible.
Use readable font sizes.
Don't rely only on hover interactions.

A calculator that works perfectly on desktop but is difficult to use on mobile will lose a significant portion of its potential audience.

6. Accuracy Matters More Than Design

A calculator can have a beautiful interface, but if the calculation is wrong, users will stop trusting it.

Developers should test calculators with:

Normal values
Zero values
Very large values
Decimal values
Negative values where applicable
Empty inputs
Boundary values

For financial or scientific calculators, testing should also compare results against trusted formulas or reference calculations.

7. Don't Forget Units

Unit conversion introduces another common source of errors.

For example, converting kilometers to miles requires a defined conversion factor:

function kilometersToMiles(km) {
    return km * 0.621371;
}

For calculators involving multiple units, it is better to centralize conversion factors rather than duplicating them throughout the application.

8. SEO for Calculator Websites

Calculators can also be useful search-engine landing pages when they solve a specific problem.

Instead of creating a page that only contains a calculator widget, developers can provide useful supporting information:

What the calculator does
The formula used
Step-by-step examples
Common questions
Explanation of inputs
Limitations of the calculation

This creates a better experience for both users and search engines.

For example, instead of having only a "Percentage Calculator", a page could explain percentage increase, percentage decrease, the underlying formula, and several practical examples.

9. Build Small Tools That Solve Real Problems

You don't always need a complicated application to create something useful.

A simple calculator that solves a common problem can be more valuable than a large application that nobody needs.

The best approach is usually:

Identify a problem → define the formula → build a simple interface → validate inputs → explain the result → test extensively.

That process can turn a basic JavaScript function into a genuinely useful web tool.

Final Thoughts

Online calculators are a good example of how relatively simple programming concepts can become useful products.

The mathematics may sometimes be straightforward, but creating a reliable calculator requires attention to validation, usability, accuracy, accessibility, mobile design, and clear explanations.

Whether you're building a calculator as a learning project or as part of a larger utility website, focus first on correctness and usefulness.

A calculator that solves one real problem accurately is often more valuable than a complicated tool that tries to do everything.

How I Built 250+ Free Online Calculators Using HTML, CSS, and JavaScript

Naveen Hooda — Sun, 19 Jul 2026 07:58:00 +0000

Building websites is easy.

Building 250+ fast, SEO-friendly calculators that are easy to maintain is a completely different challenge.

Over the past few months, I've been working on Erapse, a platform that provides free online calculators and utility tools. The goal is simple:

Help people solve everyday problems quickly without requiring sign-ups, downloads, or unnecessary complexity.

Why I Started This Project

While searching online, I noticed that many calculators either:

Are overloaded with advertisements
Load slowly
Provide very little explanation
Aren't optimized for mobile devices
Cover only a single category

I wanted to build one platform where users could access calculators for different needs from one place.

Examples include:

Finance
Health
Education
Date & Time
Unit Conversion
Productivity
Utility Tools
Tech Stack

I intentionally kept the stack simple.

HTML5
CSS3
Bootstrap
Vanilla JavaScript

No heavy frontend framework.

The main reason was performance and SEO.

Each calculator loads almost instantly because there is very little JavaScript compared to a typical SPA.

Reusable Architecture

Instead of writing every calculator from scratch, I built reusable components.

For example:

Common input validation
Shared UI components
Error handling
Copy/Reset functionality
Responsive layout
Shared styling

That allows me to create new calculators much faster while keeping the user experience consistent.

SEO Considerations

Every calculator page includes:

Unique title
Meta description
Structured headings
Human-readable explanations
Formula (when applicable)
FAQs
Related calculator links

I also focused on:

Fast page speed
Mobile responsiveness
Clean URLs
Internal linking
Challenges

One thing I learned is that publishing hundreds of pages doesn't automatically generate traffic.

The biggest challenges have been:

Getting pages indexed
Building topical authority
Creating genuinely useful content
Improving internal linking
Earning trust from search engines

SEO is definitely a long-term process.

Lessons Learned

Some things I'd recommend if you're building a similar project:

✅ Keep your code reusable.

✅ Focus on page speed.

✅ Don't overcomplicate the frontend.

✅ Write content that actually helps users.

✅ Publish consistently.

✅ Be patient with SEO.

What's Next?

I'm continuing to expand the platform with more calculators and utility tools.

Some upcoming categories include:

Government-related calculators
Developer utilities
PDF tools
AI-powered utilities
Productivity tools
India-specific calculators

The long-term goal is to build a comprehensive collection of useful online tools that anyone can access for free.

I'd Love Your Feedback

If you've built a large static website or a utility platform, I'd love to hear about your experience.

How do you organize hundreds of pages?
What SEO strategies have worked well for you?
Any suggestions for improving scalability or maintainability?

I'm always interested in learning from other developers.

Project: https://erapse.com

If you have feedback or ideas for new calculators or utility tools, feel free to share them in the comments.