DEV Community: hammadrasool2000-svg

How Salary Income Tax Is Calculated in Pakistan for 2026-27 (With Code)

hammadrasool2000-svg — Sat, 17 Oct 2026 17:16:51 +0000

If you build payroll, HR or fintech software for Pakistan, or you just want to check your own salary slip, you need to know how salary tax is calculated. The good news: once you understand the slab formula, it's a few lines of code.

This post covers tax year 2027, which runs from 1 July 2026 to 30 June 2027 (commonly called "2026-27"), under the Finance Act 2026.

Source note: The slab figures below are taken from the ToolStash Pakistan Salary Tax Calculator page, which states that its slabs come from the Finance Act 2026 as reported in PwC Pakistan's Tax Memorandum and The Express Tribune. This is an explainer, not tax advice. Check the Federal Board of Revenue (FBR) or a tax adviser for your exact liability.

Who these slabs apply to

These rates apply to salaried individuals, meaning people whose salary is more than 75% of their taxable income. Business and other non-salaried income uses a different table.

The 2026-27 salary tax slabs

Annual taxable income (Rs)	Tax
Up to 600,000	0%
600,001 â€“ 1,200,000	1% of amount above 600,000
1,200,001 â€“ 2,200,000	6,000 + 11% of amount above 1,200,000
2,200,001 â€“ 3,200,000	116,000 + 20% of amount above 2,200,000
3,200,001 â€“ 4,100,000	316,000 + 25% of amount above 3,200,000
4,100,001 â€“ 5,600,000	541,000 + 29% of amount above 4,100,000
5,600,001 â€“ 7,000,000	976,000 + 32% of amount above 5,600,000
Above 7,000,000	1,424,000 + 35% of amount above 7,000,000

What changed from 2025-26

According to the same source:

Rs 2.2â€“3.2 million: 23% â†’ 20%
Rs 3.2â€“4.1 million: 30% â†’ 25%
Rs 4.1â€“5.6 million: 35% â†’ 29% (new slab)
Rs 5.6â€“7 million: 35% â†’ 32% (new slab)
Above Rs 7 million: 35% (rate unchanged)
The 9% surcharge on salaried taxable income above Rs 10 million was abolished.

The tax-free threshold (Rs 600,000) and the 1% and 11% slabs did not change, so anyone earning up to Rs 2.2 million a year (about Rs 183,000 a month) pays the same as last year.

How the formula works

Each slab is a fixed amount plus a percentage of the income above the slab's lower limit. The fixed amount is simply the total tax on all the slabs below it. You can check this yourself:

Top of the 1% slab: 1% Ã— (1,200,000 âˆ’ 600,000) = 6,000
Top of the 11% slab: 6,000 + 11% Ã— 1,000,000 = 116,000
Top of the 20% slab: 116,000 + 20% Ã— 1,000,000 = 316,000
Top of the 25% slab: 316,000 + 25% Ã— 900,000 = 541,000

â€¦and so on. That's why it's a marginal system: moving into a higher slab only taxes the extra rupees at the higher rate, not your whole salary.

The steps:

Monthly taxable salary Ã— 12 = annual taxable income.
Find the slab and apply its formula to get the annual tax.
Annual tax Ã· 12 = monthly deduction (your employer withholds it in 12 instalments).
Salary âˆ’ tax = take-home pay.

Worked examples

Rs 100,000 a month â†’ Rs 1,200,000 a year
1% Ã— (1,200,000 âˆ’ 600,000) = Rs 6,000 a year â†’ Rs 500 a month.

Rs 300,000 a month â†’ Rs 3,600,000 a year
316,000 + 25% Ã— (3,600,000 âˆ’ 3,200,000) = Rs 416,000 a year â†’ â‰ˆ Rs 34,667 a month.

Rs 500,000 a month â†’ Rs 6,000,000 a year
976,000 + 32% Ã— (6,000,000 âˆ’ 5,600,000) = Rs 1,104,000 a year â†’ Rs 92,000 a month.

Rs 1,000,000 a month â†’ Rs 12,000,000 a year
1,424,000 + 35% Ã— (12,000,000 âˆ’ 7,000,000) = Rs 3,174,000 a year â†’ Rs 264,500 a month.

These match the example table on the calculator page.

The code

Because each slab carries its own fixed amount, the implementation is a lookup, not a loop:

// Pakistan salary tax slabs, tax year 2027 (2026-27)
const SLABS_2026_27 = [
  { from: 0,         fixed: 0,         rate: 0.00 },
  { from: 600_000,   fixed: 0,         rate: 0.01 },
  { from: 1_200_000, fixed: 6_000,     rate: 0.11 },
  { from: 2_200_000, fixed: 116_000,   rate: 0.20 },
  { from: 3_200_000, fixed: 316_000,   rate: 0.25 },
  { from: 4_100_000, fixed: 541_000,   rate: 0.29 },
  { from: 5_600_000, fixed: 976_000,   rate: 0.32 },
  { from: 7_000_000, fixed: 1_424_000, rate: 0.35 },
];

function annualSalaryTax(annualIncome, slabs = SLABS_2026_27) {
  // find the highest slab whose lower limit is below the income
  const slab = [...slabs].reverse().find(s => annualIncome > s.from) ?? slabs[0];
  return slab.fixed + (annualIncome - slab.from) * slab.rate;
}

function monthlyBreakdown(monthlySalary) {
  const annualTax = annualSalaryTax(monthlySalary * 12);
  const monthlyTax = annualTax / 12;
  return {
    annualTax: Math.round(annualTax),
    monthlyTax: Math.round(monthlyTax),
    takeHome: Math.round(monthlySalary - monthlyTax),
  };
}

console.log(monthlyBreakdown(100_000));   // { annualTax: 6000, monthlyTax: 500, takeHome: 99500 }
console.log(monthlyBreakdown(300_000));   // { annualTax: 416000, monthlyTax: 34667, takeHome: 265333 }
console.log(monthlyBreakdown(1_000_000)); // { annualTax: 3174000, monthlyTax: 264500, takeHome: 735500 }

A few implementation tips:

Keep slabs as data, keyed by tax year. Budgets change every June, and you'll want to support the previous year for arrears and corrections.
Use the fixed amounts as a self-check. Write a unit test asserting that each slab's fixed equals the tax at the previous slab's upper limit. It catches typos instantly.
Round only at the end. Rounding the monthly figure before multiplying can drift by a few rupees over a year.
Use the taxable salary. Some allowances are exempt under the Second Schedule of the Income Tax Ordinance, so taxable salary can be lower than gross pay.

What this simple model leaves out

The slab formula is the core, but real payroll may also need to handle tax credits, zakat, exempt allowances, pension, and other income sources. Treat the output as an estimate and reconcile it against the employer's tax certificate.

If you just want to check a number without writing code, the salary tax calculator shows monthly tax, take-home pay and the change from 2025-26. It runs in the browser, so nothing you type is sent anywhere.

Convert CSV to SQL INSERT Statements Quickly (Without Breaking Your Data)

hammadrasool2000-svg — Sat, 17 Oct 2026 17:16:40 +0000

Someone sends you a spreadsheet: a customer export, a product list, a CRM dump. You need it in a database table, ideally in the next five minutes. Here's how to go from CSV to SQL INSERT statements quickly, and what to watch for so the import doesn't silently corrupt your data.

The traps (read this first)

Turning CSV into SQL looks like simple string concatenation, and that's exactly how bugs get in:

Commas inside values. "Khan, Sara" is one field, not two. Splitting on , breaks it.
Quotes inside values. O'Brien will end your SQL string early unless the quote is escaped as O''Brien.
Leading zeros. Zip codes and phone numbers like 05400 or 03001234567 become 5400 if you treat them as integers.
Empty cells. Should they be '' or NULL? Usually NULL.
Booleans and dates. true / 1 / TRUE, and dates in YYYY-MM-DD vs 14/03/2026, depend on your database.
Dialect differences. MySQL quotes names with backticks, PostgreSQL and SQLite use double quotes, SQL Server uses brackets, and SQL Server caps a single INSERT ... VALUES at 1,000 rows.

Keep these in mind whichever method you use.

Option 1: Paste it into a converter (fastest)

For a one-off import, a browser converter is the quickest route. The CSV to SQL converter on ToolStash takes pasted CSV or a .csv file and produces CREATE TABLE plus INSERT statements for MySQL/MariaDB, PostgreSQL, SQL Server, SQLite or Oracle. It handles the traps above for you:

Standard CSV quoting, so commas, line breaks and doubled quotes inside quoted fields work.
Single quotes are escaped, and empty cells become NULL.
Column types are guessed from the data (INT, DECIMAL, BOOLEAN, DATE), but values with leading zeros stay as text.
Multi-row INSERTs for faster imports, respecting the SQL Server row limit.
Delimiters (comma, semicolon, tab, pipe) are detected automatically.

It runs in the browser, so the data doesn't leave your machine. Example input:

id,name,email,signup_date,active
1,"Khan, Sara",sara@example.com,2026-03-14,true
2,Ali Raza,ali@example.com,2026-04-02,false

Output for MySQL with the table name customers:

CREATE TABLE `customers` (
  `id` INT,
  `name` VARCHAR(255),
  `email` VARCHAR(255),
  `signup_date` DATE,
  `active` BOOLEAN
);

INSERT INTO `customers` (`id`, `name`, `email`, `signup_date`, `active`) VALUES
(1, 'Khan, Sara', 'sara@example.com', '2026-03-14', TRUE),
(2, 'Ali Raza', 'ali@example.com', '2026-04-02', FALSE);

Always review the generated CREATE TABLE before running it. Inferred types are a starting point. You'll often want a primary key, a NOT NULL or two, or a longer VARCHAR.

Option 2: A small Python script (repeatable)

If you do this regularly, script it. Python's csv module handles the quoting rules correctly:

import csv
import sys

def sql_value(v):
    if v == "":
        return "NULL"
    # keep leading-zero values (zip codes, phones) as text
    if v.lstrip("-").isdigit() and not (len(v) > 1 and v.lstrip("-").startswith("0")):
        return v
    return "'" + v.replace("'", "''") + "'"

def csv_to_inserts(path, table, batch=500):
    with open(path, newline="", encoding="utf-8") as f:
        reader = csv.reader(f)
        header = next(reader)
        cols = ", ".join(f'"{c}"' for c in header)
        rows = [f"({', '.join(sql_value(v) for v in r)})" for r in reader]

    for i in range(0, len(rows), batch):
        chunk = ",\n".join(rows[i:i + batch])
        print(f'INSERT INTO "{table}" ({cols}) VALUES\n{chunk};\n')

csv_to_inserts(sys.argv[1], sys.argv[2])

Run it:

python csv_to_sql.py customers.csv customers > customers.sql
psql mydb -f customers.sql

This version uses double-quoted identifiers (PostgreSQL/SQLite style). Swap in backticks for MySQL. Batching keeps each statement a reasonable size.

Option 3: Skip INSERTs entirely for big files

For hundreds of thousands of rows, generated INSERT statements are the slow way. Every database has a native bulk loader:

-- PostgreSQL (from psql)
\copy customers FROM 'customers.csv' WITH (FORMAT csv, HEADER true);

-- MySQL
LOAD DATA LOCAL INFILE 'customers.csv'
INTO TABLE customers
FIELDS TERMINATED BY ',' ENCLOSED BY '"'
LINES TERMINATED BY '\n'
IGNORE 1 LINES;

-- SQL Server
BULK INSERT customers FROM 'C:\data\customers.csv'
WITH (FORMAT = 'CSV', FIRSTROW = 2);

These still need the table to exist. A handy workflow is to generate just the CREATE TABLE with a converter, adjust it, then bulk-load the file. ToolStash has a longer guide to importing CSV with LOAD DATA, \copy and BULK INSERT if you need the details for each database.

When to use what

Situation	Best approach
One-off, a few thousand rows	Paste into a converter, review, run
Recurring import, same format	Python (or your language) script
Very large file	Native bulk loader (`\copy`, `LOAD DATA`, `BULK INSERT`)
Excel file	Save as CSV first, then any of the above

Final checks before you hit Run

Open the CSV in a text editor (not Excel) to check the delimiter and encoding. UTF-8 avoids broken characters.
Confirm the header row is present, or name the columns yourself.
Spot-check rows with commas, quotes and empty cells in the output.
Run it inside a transaction (BEGIN; ... ROLLBACK;) first if you're importing into a shared database.

With quoting, NULLs and leading zeros handled properly, a CSV-to-SQL import is a five-minute job.

How to Compare Two JSON Files and Actually Spot the Differences

hammadrasool2000-svg — Sat, 17 Oct 2026 17:16:20 +0000

You have two JSON files: yesterday's API response and today's, or the staging config and the production config. Something is different and you need to find it. You run diff a.json b.json and get a single changed line 4,000 characters long. Not much help.

The problem isn't the diff tool. JSON is often minified, keys come back in a different order, and indentation varies. A text diff compares characters, not data. The fix is to normalize both files first, then diff them.

Here are three ways to do that, from quickest to most thorough.

Why raw JSON diffs are noisy

Take these two payloads:

{"id":42,"name":"Sara","roles":["admin","editor"],"active":true}

{"name":"Sara","id":42,"active":false,"roles":["admin","editor"]}

Only one value changed (active). But because the keys are in a different order and everything sits on one line, a line-based diff reports the whole thing as changed. Three things cause this noise:

Minification: everything is on one line, so any change marks the entire line as changed.
Key order: {"a":1,"b":2} and {"b":2,"a":1} hold the same data but are different text.
Whitespace and indentation: 2 spaces vs 4 spaces vs tabs.

Option 1: Pretty-print and diff in the browser (fastest)

If you just want to eyeball two payloads, paste them into a JSON-aware diff. The JSON Diff Checker on ToolStash pretty-prints both sides before comparing, putting one key on each line, so only the lines that actually changed get highlighted. You can switch between line-by-line and word-by-word views. It runs locally in the browser, so you're not uploading production data anywhere.

Two things to know:

If one side isn't valid JSON, it falls back to a plain text diff. Run the input through a JSON formatter first if you suspect a syntax error. It shows the parser's error message, so you can see exactly where it breaks.
The comparison is text-based after formatting, so key order still matters. If the two files order keys differently, sort them first (see Option 2).

Option 2: Normalize with `jq`, then use any diff tool

jq can sort keys and pretty-print in one step. The -S flag sorts object keys recursively:

jq -S . before.json > before.sorted.json
jq -S . after.json  > after.sorted.json
diff -u before.sorted.json after.sorted.json

Output for the example above:

--- before.sorted.json
+++ after.sorted.json
@@ -1,5 +1,5 @@
 {
-  "active": true,
+  "active": false,
   "id": 42,
   "name": "Sara",
   "roles": [

Now the diff shows exactly one change. If you'd rather skip the temp files, use process substitution:

diff -u <(jq -S . before.json) <(jq -S . after.json)

Or, if you use git:

git diff --no-index <(jq -S . before.json) <(jq -S . after.json)

Arrays are not sorted by -S, and that's deliberate, because array order is usually meaningful. If your array order doesn't matter (for example, a list of tags), sort it explicitly:

jq -S '.roles |= sort' before.json

Option 3: A structural diff in code

When you need the differences as data, for a test assertion or a CI check, compare the parsed objects rather than text. Here is a small recursive diff in JavaScript with no dependencies:

function jsonDiff(a, b, path = "") {
  const changes = [];
  if (typeof a !== typeof b || Array.isArray(a) !== Array.isArray(b)) {
    changes.push({ path, before: a, after: b });
  } else if (a && typeof a === "object") {
    const keys = new Set([...Object.keys(a), ...Object.keys(b)]);
    for (const key of keys) {
      const p = Array.isArray(a) ? `${path}[${key}]` : `${path}.${key}`;
      if (!(key in a)) changes.push({ path: p, added: b[key] });
      else if (!(key in b)) changes.push({ path: p, removed: a[key] });
      else changes.push(...jsonDiff(a[key], b[key], p));
    }
  } else if (a !== b) {
    changes.push({ path, before: a, after: b });
  }
  return changes;
}

const before = JSON.parse(require("fs").readFileSync("before.json", "utf8"));
const after  = JSON.parse(require("fs").readFileSync("after.json", "utf8"));
console.log(jsonDiff(before, after));
// [ { path: '.active', before: true, after: false } ]

Because it walks the parsed objects, key order doesn't matter at all. You get a clean list of paths like .user.address.city or .items[3].price, which is easy to log or fail a test on.

In Python, the standard library gets you most of the way for a quick check:

import json
a = json.load(open("before.json"))
b = json.load(open("after.json"))
print(a == b)  # dict comparison ignores key order
print(json.dumps(a, sort_keys=True, indent=2))  # normalized, ready to diff

For larger projects, libraries like deepdiff (Python) or jsondiffpatch (JS) give you richer output, including array moves.

A quick checklist

Is it valid JSON? Validate before you diff, or you'll be comparing error noise.
Pretty-print both sides with the same indentation.
Sort keys if they can come back in any order (jq -S, sort_keys=True).
Decide whether array order matters. Sort arrays only when it doesn't.
Ignore volatile fields like timestamps or request IDs: jq 'del(.meta.requestId)'.
Use a structural diff in tests, and a visual diff for debugging.

Normalize first, diff second. Once you do that, a JSON diff shows only the fields that actually changed.

Why I Built ToolStash: Free, Client-Side Developer Tools

hammadrasool2000-svg — Fri, 18 Sep 2026 20:27:26 +0000

Every developer has a handful of five-second tasks that come up constantly — pretty-printing a blob of JSON, generating a UUID for a test fixture, checking why two config files don't match. Most tool sites for this are slow, ad-choked, or ask you to sign up for something you'll use twice a year.

That's why I built ToolStash — a small, growing collection of developer utilities that run entirely in the browser:

Diff Checker — line-by-line or word-by-word comparison
Hash Generator — MD5, SHA-1, SHA-256, SHA-512, NTLM
UUID Generator — single or bulk (up to 100 at once)
JSON Formatter — beautify, validate, minify
YAML to JSON Converter
Markdown to HTML Converter — with live preview
SQL Formatter — supports MySQL, PostgreSQL, SQL Server, Oracle, BigQuery, Snowflake, SQLite
Regex Tester — live match highlighting and capture groups

Why client-side only?

Every tool runs as plain JavaScript in your browser. There's no backend for your input to pass through, so nothing you paste is ever uploaded — which matters if you're debugging something with real (if low-stakes) data in it, like a config file or a sample record.

What's next

I'm adding new tools regularly — base64 encode/decode, a cron expression builder, and a password generator are next up. If there's a utility you find yourself needing often, I'd love to hear about it in the comments.

Try it: https://toolstash.tools