DEV Community: Code Wiz Tools

How to Calculate CGPA — Complete Guide for Pakistani University Students

Code Wiz Tools — Sat, 27 Jun 2026 09:15:06 +0000

If you are a university student in Pakistan, you have probably asked at least one of these questions:

"What is my current CGPA?"
"How many As do I need to get off academic probation?"
"What CGPA do I need for a Gold Medal?"

This guide answers all of them — with the exact formula, worked examples, a grade conversion table, and a CGPA to percentage formula.

What is GPA and CGPA?

GPA (Grade Point Average) is your academic performance score for a single semester. It ranges from 0.0 to 4.0.

CGPA (Cumulative Grade Point Average) is your overall academic performance across all semesters combined. It is a weighted average of all your semester GPAs, weighted by credit hours.

Think of GPA as your score for one match, and CGPA as your season average.

The Grade Scale — 4.0 Standard

Most Pakistani universities (FAST-NUCES, NUST, COMSATS, UET, Punjab University, LUMS) use the 4.0 grade scale:

Grade	Grade Points	Percentage (approx.)
A / A+	4.00	90–100%
A−	3.66	85–89%
B+	3.33	80–84%
B	3.00	75–79%
B−	2.66	70–74%
C+	2.33	65–69%
C	2.00	60–64%
C−	1.66	55–59%
D+	1.30	50–54%
D	1.00	45–49%
F	0.00	Below 45%

How to Calculate Semester GPA — The Formula

GPA = Σ (Grade Points × Credit Hours) ÷ Total Credit Hours

Step by step:

For each subject, multiply the grade points by the credit hours
Add all those products together
Divide by the total credit hours across all subjects

Worked Example

Say you completed 5 subjects this semester:

Subject	Credits	Grade	Grade Points	Points × Credits
Data Structures	3	A	4.00	12.00
OOP	3	B+	3.33	9.99
Calculus	3	B	3.00	9.00
Digital Logic	3	A−	3.66	10.98
Physics Lab	1	B+	3.33	3.33
Total	13			45.30

GPA = 45.30 ÷ 13 = 3.48

Your semester GPA is 3.48 — Dean's List territory at most universities.

How to Calculate Cumulative CGPA

Once you have multiple semesters, CGPA is the weighted average of all semester GPAs:

CGPA = Σ (Semester GPA × Semester Credits) ÷ Total Credits

Worked Example — 4 Semesters

Semester	GPA	Credits	GPA × Credits
Semester 1	3.20	18	57.60
Semester 2	3.48	13	45.24
Semester 3	3.75	18	67.50
Semester 4	3.10	18	55.80
Total		67	226.14

CGPA = 226.14 ÷ 67 = 3.37

Your cumulative CGPA is 3.37.

Notice that Semester 3 (GPA 3.75) carries more weight than Semester 2 (GPA 3.48) because it had more credit hours. This is why taking extra courses in a good semester can significantly lift your CGPA.

How to Convert CGPA to Percentage

The most widely used formula at Pakistani universities:

Percentage = CGPA × 25

CGPA	Percentage
4.00	100%
3.75	93.75%
3.50	87.5%
3.00	75%
2.50	62.5%
2.00	50%

Note: Some universities use CGPA × 24 or other multipliers. Always check your university's official transcript or academic policy for the exact conversion — it can vary by department.

CGPA Thresholds at Pakistani Universities

Most universities follow a similar scale for awards and academic standing:

Gold Medal / President's Honor Roll: CGPA 3.5 to 4.0
Usually awarded to the top 1–3 students in a degree program at convocation.

Dean's List / Silver Medal: CGPA 3.0 to 3.49
Recognized on your transcript and at convocation. Some universities require 3.0+ every semester.

Good Standing: CGPA 2.5 to 2.99
You are meeting requirements and progressing normally.

Satisfactory / Minimum: CGPA 2.0 to 2.49
You are passing but may face restrictions on elective choices.

Academic Probation: Below CGPA 2.0
At FAST-NUCES, NUST, COMSATS, and most other universities, falling below 2.0 triggers academic probation. You may be required to repeat subjects, reduce credit load, or face expulsion after multiple semesters on probation.

3 Common CGPA Mistakes Students Make

Mistake 1 — Not counting lab credit hours

Lab courses are usually 1 credit hour. Students often forget to include them in the calculation. A failed lab (F = 0.00) in 1 credit hour pulls your GPA down more than you expect relative to its small credit weight.

Mistake 2 — Ignoring low-credit subjects

A 1-credit hour subject with an A (4.0) contributes far less to your GPA than a 3-credit subject with a B (3.0). Focus your exam preparation time proportional to credit hours.

Mistake 3 — Thinking one bad semester is permanent

Because CGPA is a weighted average across all semesters, one bad semester does less damage than it feels like. If you score 3.80 GPA in a strong 21-credit semester, it will significantly offset a weaker previous semester. Recovery is possible — but it requires consistently strong semesters, not just one good one.

How to Calculate: What GPA Do I Need This Semester?

You have a CGPA of 2.9 after 3 semesters (54 total credits) and want to reach 3.0 by the end of next semester (18 credits).

Target CGPA = (Current GPA × Current Credits + Next GPA × Next Credits) 
              ÷ (Current Credits + Next Credits)

3.0 = (2.9 × 54 + X × 18) ÷ (54 + 18)
3.0 × 72 = 156.6 + 18X
216 = 156.6 + 18X
18X = 59.4
X = 3.30

You need a 3.30 GPA next semester to bring your CGPA up to 3.0.

This type of target GPA calculation is useful for planning how hard you need to work in an upcoming semester to reach a specific goal.

Free CGPA Calculator

If you do not want to do this by hand, I built a free CGPA Calculator that handles both semester GPA and cumulative CGPA:

Add subjects with grade and credit hours → Semester GPA calculated instantly
Add multiple semesters → Cumulative CGPA calculated with correct credit weighting
Grade scale table built in — no manual lookup needed
Shows CGPA to percentage conversion automatically
100% browser-based — your academic data never leaves your device

Summary

GPA formula: Sum of (Grade Points × Credits) ÷ Total Credits
CGPA formula: Sum of (Semester GPA × Semester Credits) ÷ Total Credits
CGPA to percentage: CGPA × 25 (verify with your university)
Gold Medal threshold: 3.5+ at most Pakistani universities
Academic probation: Below 2.0 at most universities
One bad semester is recoverable — consistent strong semesters are the strategy

Check out CodeWizTools for more free tools built for students and developers — attendance calculator, assignment file renamer, PDF merger, and more.

Base64 Encoding Explained — JWT Tokens, Data URIs, and Kubernetes Secrets

Code Wiz Tools — Thu, 25 Jun 2026 22:17:00 +0000

You have probably copied a Base64 string a hundred times without thinking about it. That long chain of letters and slashes at the end of a JWT. The data:image/png;base64, blob in a CSS file. The Authorization: Basic header in a Postman collection.

Base64 is everywhere in a developer's daily work — and most developers have a fuzzy mental model of what it actually does. This article clears that up, and covers the five real production use cases where you will encounter it.

What is Base64 and why does it exist?

Base64 converts binary data into a string of 64 printable ASCII characters: the letters A–Z and a–z, digits 0–9, plus + and /. The name literally describes the alphabet size.

The reason it exists: many systems that move data were designed for text only. Email protocols (SMTP), HTML attributes, JSON payloads, XML documents, HTTP headers — all of these were built around the assumption that data is readable ASCII text. Raw binary bytes can corrupt or break these systems.

Base64 solves this by guaranteeing that whatever you encode will contain only characters that transmit safely through any text-based system.

The size tradeoff

Base64 encodes every 3 bytes of input into 4 output characters. That means encoded output is always approximately 33% larger than the original data. This is the price of universality.

The = or == at the end of a Base64 string is padding — added when the input length is not divisible by 3. One = means one byte of padding was needed; == means two bytes. Never strip padding manually — it is part of the RFC 4648 standard and removing it breaks decoding.

Base64 is NOT encryption

This is the most important thing to understand, and it gets confused constantly.

Base64 is encoding, not encryption. Anyone can decode it instantly with zero key or password. There is nothing protecting the data — it is just a different representation.

// This is NOT secure
const "secret" = btoa("admin:password123");
// Result: YWRtaW46cGFzc3dvcmQxMjM=
// Anyone can run atob("YWRtaW46cGFzc3dvcmQxMjM=") and read it

// This is what it looks like in an HTTP Basic Auth header
// Authorization: Basic YWRtaW46cGFzc3dvcmQxMjM=
// The credentials are completely readable — this is just transport formatting

Never store passwords, API secrets, or private tokens as Base64 and assume they are secure. Use proper encryption (AES-256, bcrypt, Argon2) when you need actual protection.

The 5 places you will encounter Base64 in production

1. JWT Tokens

A JWT (JSON Web Token) has three Base64URL-encoded parts separated by dots:

eyJhbGciOiJIUzI1NiJ9.eyJ1c2VyIjoiYWxpY2UifQ.abc123sig
     ^header                  ^payload              ^signature

The header and payload are Base64URL encoded — not standard Base64. Base64URL is a URL-safe variant that replaces + with - and / with _ to avoid issues in URLs and HTTP headers.

To read a JWT payload without a library:

Take the middle section (between the two dots)
Replace all - with +
Replace all _ with /
Decode from Base64

function decodeJwtPayload(token) {
  const payload = token.split('.')[1];
  // Convert Base64URL to standard Base64
  const base64 = payload.replace(/-/g, '+').replace(/_/g, '/');
  return JSON.parse(atob(base64));
}

// Usage
const token = "eyJhbGciOiJIUzI1NiJ9.eyJ1c2VyIjoiYWxpY2UiLCJleHAiOjE3MjAwMDAwMDB9.sig";
console.log(decodeJwtPayload(token));
// → { user: "alice", exp: 1720000000 }

You can also use the Base64 decoder on CodeWizTools to decode JWT payloads manually — paste the middle section and the tool decodes it to readable JSON.

Note: Never verify a JWT by just decoding the payload. Always verify the signature server-side. Client-side JWT decoding is fine for reading claims (user ID, role, expiry) — but never trust unverified claims for authorization decisions.

2. HTTP Basic Authentication

HTTP Basic Auth sends credentials in the Authorization header as Base64-encoded username:password:

Authorization: Basic YWRtaW46cGFzc3dvcmQxMjM=

Decoded: admin:password123

This is the standard format for API basic auth. Most REST clients (Postman, curl, Insomnia) handle this automatically, but knowing the encoding format helps when you are debugging raw HTTP requests or writing test scripts.

# curl with Basic Auth — curl encodes this for you
curl -u admin:password123 https://api.example.com/data

# Equivalent with manual header
curl -H "Authorization: Basic YWRtaW46cGFzc3dvcmQxMjM=" https://api.example.com/data

3. Data URIs — Embedding Images in HTML and CSS

A data URI lets you embed a file directly into HTML or CSS without a separate HTTP request:

<!-- Standard image tag with external URL -->
<img src="https://example.com/icon.png" alt="Icon">

<!-- Same icon embedded as Base64 data URI — no HTTP request needed -->
<img src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAEAAAABCAYAAAAfFcSJAAAADUlEQVR42mNk+M9QDwADhgGAWjR9awAAAABJRU5ErkJggg=" alt="Icon">

The format is:

data:[media type];base64,[Base64 encoded data]

When to use data URIs:

Small icons (under 2–3 KB) that are critical for above-the-fold rendering
Email templates — external images are often blocked by email clients
Canvas-generated images you want to save or display

When NOT to use them:

Images over ~5 KB — the 33% size overhead becomes significant
Images used on multiple pages — they cannot be cached separately
Lazy-loaded content — data URIs cannot be lazy loaded

4. Kubernetes Secrets

Every value in a Kubernetes Secret manifest must be Base64-encoded:

apiVersion: v1
kind: Secret
metadata:
  name: db-credentials
type: Opaque
data:
  username: YWRtaW4=          # base64 of "admin"
  password: cGFzc3dvcmQxMjM=  # base64 of "password123"

This is a common point of confusion for developers new to Kubernetes — it looks like the credentials are protected, but Base64 is just encoding, not encryption. Kubernetes Secrets are not inherently secure; you need additional tooling (Sealed Secrets, HashiCorp Vault, AWS Secrets Manager) for real secret management.

# Encoding a secret value for a Kubernetes manifest
echo -n "password123" | base64
# Output: cGFzc3dvcmQxMjM=

# The -n flag is important — without it, echo adds a newline
# which gets encoded and causes authentication failures

5. Sending Binary Files in JSON APIs

REST APIs that use JSON cannot transmit raw binary data (images, PDFs, audio files) directly. Base64 is the standard workaround:

{
  "filename": "report.pdf",
  "content_type": "application/pdf",
  "data": "JVBERi0xLjQKJcOkw7zDtsOfCjIgMCBvYmoKPDwvTGVuZ3Ro..."
}

This pattern is used in email APIs (SendGrid, Mailgun), document processing APIs, and any API that needs to receive or send files over a JSON interface.

The Unicode problem — why most Base64 tools break

The browser's built-in btoa() function only handles ASCII. Try encoding text with non-ASCII characters and you will get an error:

btoa("اردو");
// → Uncaught DOMException: The string to be encoded 
//   contains characters outside of the Latin1 range.

btoa("😀");
// → Same error

The correct way to encode Unicode text to Base64 in JavaScript:

// WRONG — breaks on any non-ASCII character
const broken = btoa(text);

// CORRECT — handles full Unicode (Arabic, Urdu, Chinese, emoji)
function encodeBase64Unicode(str) {
  const bytes = new TextEncoder().encode(str);
  let binary = '';
  bytes.forEach(byte => binary += String.fromCharCode(byte));
  return btoa(binary);
}

function decodeBase64Unicode(base64) {
  const binary = atob(base64);
  const bytes = new Uint8Array(binary.length);
  for (let i = 0; i < binary.length; i++) {
    bytes[i] = binary.charCodeAt(i);
  }
  return new TextDecoder().decode(bytes);
}

// Now these work
encodeBase64Unicode("اردو");     // → "2KfYsdm/2Yg="
encodeBase64Unicode("😀");      // → "8J+YgA=="
encodeBase64Unicode("中文");     // → "5Lit5paH"

TextEncoder converts the string to UTF-8 bytes first, then btoa encodes those bytes. TextDecoder reverses the process. This is the correct standard per RFC 4648 and is what major frameworks and APIs use.

The older pattern btoa(unescape(encodeURIComponent(str))) also works but uses the deprecated unescape() function — avoid it in new code.

Base64 vs Base64URL — which one is it?

Standard Base64 uses + and / in its alphabet. These characters have special meaning in URLs (+ = space in query strings, / = path separator), which causes problems when Base64 strings appear in URLs or HTTP headers.

Base64URL solves this by substituting:

+ → -
/ → _

And optionally omitting the = padding.

Context	Format	Characters
JWT tokens	Base64URL	A–Z, a–z, 0–9, `-`, `_`
Kubernetes secrets	Standard Base64	A–Z, a–z, 0–9, `+`, `/`
Data URIs	Standard Base64	A–Z, a–z, 0–9, `+`, `/`
HTTP Basic Auth	Standard Base64	A–Z, a–z, 0–9, `+`, `/`
OAuth 2.0 PKCE	Base64URL	A–Z, a–z, 0–9, `-`, `_`

If you see - and _ in a Base64-looking string, it is Base64URL (almost certainly a JWT).

Quick reference

// Standard encode/decode (ASCII only — breaks on Unicode)
btoa("hello")          // → "aGVsbG8="
atob("aGVsbG8=")       // → "hello"

// Unicode-safe encode/decode (use this in production)
encodeBase64Unicode("اردو")   // → "2KfYsdm/2Yg="
decodeBase64Unicode("2KfYsdm/2Yg=")  // → "اردو"

// Decode a JWT payload (read-only — does not verify signature)
decodeJwtPayload("eyJhbGciOiJIUzI1NiJ9.eyJ1c2VyIjoiYWxpY2UifQ.sig")
// → { user: "alice" }

// Encode for Kubernetes secret (CLI)
echo -n "my-secret-value" | base64

Tool

For quick encoding and decoding without writing code — I built a free Base64 Encoder & Decoder that handles full Unicode correctly (Arabic, Urdu, Chinese, emoji), supports JWT payload decoding, and runs 100% in the browser with no data sent to any server. Useful for inspecting JWT tokens during API development, preparing Kubernetes secret values, and debugging Base64 encoding issues.

Summary

Base64 converts binary data to printable ASCII text — not encryption
It appears in JWT tokens (Base64URL variant), HTTP auth, data URIs, Kubernetes secrets, and JSON file APIs
Standard btoa() breaks on Unicode — use TextEncoder + btoa instead
Base64URL uses - and _ instead of + and / — look for it in JWTs and OAuth
Encoded output is ~33% larger than input — factor this in for data URIs and API payloads

Building something with CodeWizTools? Check out the full collection of free browser-based utilities at codewiztools.com — JSON formatter, URL encoder, RGBA color picker, Lorem Ipsum generator, and more.

URL Encoding vs Percent Encoding — Are They the Same Thing?

Code Wiz Tools — Sat, 20 Jun 2026 14:38:43 +0000

Most developers use these two terms interchangeably. Stack Overflow threads mix them up. Documentation switches between them mid-paragraph. Even MDN uses both terms in the same article.
So are they the same thing — or is there a real difference?
Short answer: they refer to the same mechanism, but come from different contexts. Understanding which is which will save you from some genuinely painful debugging sessions.
What is URL Encoding?

URL encoding is the informal, developer-facing term for converting unsafe characters in a URL into a format that can be safely transmitted over the internet.
The core problem it solves: URLs can only contain a limited set of characters. Letters (A–Z, a–z), digits (0–9), and a handful of symbols (-, _, ., ~) are always safe. Everything else — spaces, ampersands, equal signs, non-English characters — can break URL parsing if left as-is.
URL encoding converts those unsafe characters into a % sign followed by a two-digit hexadecimal code.
hello world → hello%20world
café → caf%C3%A9
q=a&b → q%3Da%26b
This term became common because browsers, frameworks, and tutorials all started calling it "URL encoding" — it is descriptive and practical.
What is Percent Encoding?
Percent encoding is the official, RFC-defined term for the exact same mechanism.
It is formally defined in RFC 3986 — the Internet standard that defines the syntax of URIs (Uniform Resource Identifiers). The spec calls it "percent-encoding" because every encoded character is represented as a percent sign followed by two hexadecimal digits.
From RFC 3986:

A percent-encoding mechanism is used to represent a data octet in a component when that octet's corresponding character is outside the allowed set or is being used as a delimiter of, or within, the component.

So when you are reading a W3C spec, an HTTP RFC, or any formal documentation — you will see "percent encoding." When you are reading a tutorial, a Stack Overflow answer, or framework docs — you will see "URL encoding."
Same thing. Different contexts.
The Real Difference You Actually Need to Know
Here is where it gets practical — and where most bugs come from.
In JavaScript, you have two built-in functions for encoding URLs. They are not interchangeable:
encodeURI vs encodeURIComponent — Code Examples
The Wrong Way (a very common mistake)

const searchUrl = "https://example.com/search?q=hello world&lang=en";
// WRONG — using encodeURIComponent on a full URL
encodeURIComponent(searchUrl);
// → "https%3A%2F%2Fexample.com%2Fsearch%3Fq%3Dhello%20world%26lang%3Den"
// The URL is now completely broken — slashes, colons, question marks all encoded
This is the most common mistake. The URL looks encoded, but it is useless — a browser cannot parse it as a URL anymore.
The Right Way — encodeURI for full URLs
const searchUrl = "https://example.com/search?q=hello world&lang=en";

// CORRECT — encodeURI preserves URL structure
encodeURI(searchUrl);
// → "https://example.com/search?q=hello%20world&lang=en"
// Only the space is encoded — the URL structure is intact

The Right Way — encodeURIComponent for query values
const userInput = "hello world & more";
const baseUrl = "https://example.com/search?q=";

// CORRECT — encode only the VALUE, not the whole URL
const fullUrl = baseUrl + encodeURIComponent(userInput);
// → "https://example.com/search?q=hello%20world%20%26%20more"
// The & inside the value is encoded to %26 — no ambiguity

Real-world example — passing a redirect URL in a query string
// You want to pass this URL as a query parameter value
const redirectUrl = "https://myapp.com/dashboard?tab=settings";

// WRONG — this breaks the outer URL's query string
"https://auth.example.com/login?redirect=" + redirectUrl;
// → "https://auth.example.com/login?redirect=https://myapp.com/dashboard?tab=settings"
// The second ? and = confuse every URL parser

// CORRECT — encode the redirect value first
"https://auth.example.com/login?redirect=" + encodeURIComponent(redirectUrl);
// → "https://auth.example.com/login?redirect=https%3A%2F%2Fmyapp.com%2Fdashboard%3Ftab%3Dsettings"
// Clean — outer URL parses correctly, inner URL recoverable via decodeURIComponent

The One-Line Rule to Remember
Use encodeURIComponent when encoding a value that goes inside a URL.
Use encodeURI when encoding a complete URL as a string.

If you remember nothing else from this article, remember that line. It will prevent 90% of URL encoding bugs.

Tool
If you need to quickly encode or decode URLs without writing code — I built a free URL Encoder & Percent Encoding Converter that supports both encodeURI and encodeURIComponent modes, handles full Unicode including Arabic and Urdu, and runs 100% in the browser with no data sent to any server.
It also includes the full percent encoding reference table and a real-time character counter — useful when debugging API calls or OAuth redirect parameters.
Conclusion
URL encoding and percent encoding are the same mechanism — one term is informal and developer-friendly, the other is the official RFC standard. The distinction that actually matters day-to-day is encodeURI vs encodeURIComponent — and using the wrong one is responsible for a surprising number of broken integrations, failed API calls, and corrupted redirect flows.
When in doubt: if you are encoding a value that goes inside a URL, use encodeURIComponent. Every time.

Found this useful? I am building CodeWizTools — a collection of free, browser-based utilities for developers and students. No login, no server uploads, 100% private.