DEV Community: Neeraj Verma

JWT 101: The Go Developer's Guide to Secure Authentication

Neeraj Verma — Sun, 08 Feb 2026 09:24:00 +0000

In the world of modern web development, JSON Web Tokens (JWT) have become the gold standard for handling authentication and secure data exchange. But what exactly happens when a server issues a token? Is it encrypted? Can anyone read it?

This guide breaks down the mechanics of JWTs, clarifies the common confusion between “encoding” and “encryption,” and shows you how to implement them in Go (Golang).

The Mechanics: How JWT Works

A JWT is a compact, URL-safe means of representing claims to be transferred between two parties. Unlike traditional session-based authentication where the server keeps a record of logged-in users (stateful), JWTs are stateless. The token itself contains all the necessary information to verify the user.

1. The Anatomy of a Token

If you look at a JWT, it appears as a long string of random characters separated by two dots. It follows this structure:

Header.Payload.Signature

Header: Indicates the algorithm used (e.g., HS256) and the token type (JWT).
Payload: Contains the “Claims” (user data like ID, role, expiration time).
Signature: The security seal.

2. Secrecy vs. Integrity

A common question developers ask is: “If the token is just Base64 encoded, can’t anyone read the signature and the payload?”

The answer is yes. Anyone who intercepts the token can decode and read the payload. However, the security of a JWT doesn’t come from hiding the data; it comes from ensuring the data hasn’t been changed.

The “Wax Seal” Analogy

Think of a JWT like a letter sent by a King (the Server) to a Messenger (the Client).

The Payload: The content of the letter (“Give this messenger 10 gold coins”).
The Signature: The King’s wax seal stamped at the bottom.

Anyone can see the wax seal. It isn’t hidden. But no one can copy or forge the seal because they don’t have the King’s signet ring (the Secret Key ).

If a thief changes the letter to say “Give this messenger 10,000 gold coins,” the wax seal will no longer match the content. They cannot “re-seal” the letter because they lack the King’s ring.

The Technical Reality: Encoding vs. Encryption

The signature is not plain text , nor is it encrypted. It is a binary cryptographic hash that is Base64Url encoded.

The Math: The server takes the Header and Payload and runs them through a hashing algorithm (like HMAC-SHA256) using a Secret Key.
The Encoding: The output of this hash is raw binary data (bytes). To make it safe for URLs and HTTP headers, we Base64Url Encode these bytes into text characters (A-Z, 0-9, -, _).

This ensures that even though anyone can read the token, no one can generate a valid signature for a fake payload without your server’s secret key.

Implementing JWT in Golang

Let’s look at how to implement this using the industry-standard package github.com/golang-jwt/jwt/v5.

Step 1: Define Your Claims

First, we define what data we want to store inside the token.

import (
    "github.com/golang-jwt/jwt/v5"
    "time"
)

// Define a custom struct to hold the token claims
type UserClaims struct {
    UserID string `json:"user_id"`
    Role string `json:"role"`
    jwt.RegisteredClaims // Embed standard claims (exp, iss, etc.)
}

// In production, keep this safe! Never hardcode it in your source code.
var jwtKey = []byte("my_secret_key")

Step 2: Generating a Token (Login)

When a user logs in successfully, we generate the token. Notice how we “sign” it at the end—this is where the hashing happens.

func GenerateToken(userID, role string) (string, error) {
    // 1. Create the Claims
    claims := UserClaims{
        UserID: userID,
        Role: role,
        RegisteredClaims: jwt.RegisteredClaims{
            ExpiresAt: jwt.NewNumericDate(time.Now().Add(15 * time.Minute)), // Short expiry!
            Issuer: "my-app",
        },
    }

    // 2. Create the token using the HS256 algorithm
    token := jwt.NewWithClaims(jwt.SigningMethodHS256, claims)

    // 3. Sign the token with our secret key
    // This generates the binary hash and Base64 encodes it for you
    signedToken, err := token.SignedString(jwtKey)
    if err != nil {
        return "", err
    }

    return signedToken, nil
}

Step 3: Validating the Token (Middleware)

When the server receives a token, it doesn’t “decrypt” it. Instead, it re-calculates the hash using the jwtKey to see if it matches the signature provided.

func VerifyToken(tokenString string) (*UserClaims, error) {
    // Parse the token
    token, err := jwt.ParseWithClaims(tokenString, &UserClaims{}, func(token *jwt.Token) (interface{}, error) {
        // Validate the alg is what you expect (Crucial security step!)
        if _, ok := token.Method.(*jwt.SigningMethodHMAC); !ok {
            return nil, fmt.Errorf("unexpected signing method: %v", token.Header["alg"])
        }
        return jwtKey, nil
    })

    if err != nil {
        return nil, err
    }

    // Check if the token is valid (signature match) and not expired
    if claims, ok := token.Claims.(*UserClaims); ok && token.Valid {
        return claims, nil
    }

    return nil, fmt.Errorf("invalid token")
}

When Should You Use JWT?

1. Authorization & Single Sign-On (SSO)

This is the most common use case. Because JWTs are self-contained, they are easily passed between different domains (e.g., auth.example.com and app.example.com), making them perfect for SSO.

2. Secure Information Exchange

Because the tokens are signed, the receiver can be 100% sure that the sender is who they claim to be. If the signature matches, the data is authentic.

Pros and Cons of JWT

The Pros

Stateless Scalability: The server doesn’t need to store session info, making it trivial to scale across multiple servers.
Mobile Friendly: Native mobile apps handle JSON and headers much easier than cookies.
Performance: No database lookup is required to verify the token (only to check revocation lists if you use them).

The Cons & Security Considerations

Payload Visibility: Never put passwords or sensitive personal data (PII) in the payload. Remember, anyone can base64 decode it and read it.
Revocation Difficulty: You cannot “log out” a user instantly by deleting a server session.
- Solution: Use Short-Lived Access Tokens (e.g., 15 mins) paired with Refresh Tokens.
Storage Matters:
- LocalStorage: Vulnerable to XSS (Cross-Site Scripting).
- HttpOnly Cookies: Vulnerable to CSRF, but safer against XSS. Recommended for web apps.

Summary

JWTs offer a modern, lightweight approach to authentication. The key takeaway is that they guarantee integrity , not secrecy. The signature ensures that the data you receive is exactly what was sent, signed by a trusted party. By understanding this distinction, you can build secure, scalable Go applications without falling into common security traps.

UTF-8: The Universal Language of the Digital World

Neeraj Verma — Sun, 05 Oct 2025 08:50:00 +0000

The modern internet, filled with languages, symbols, and emojis, relies on an ingenious, invisible system to ensure text looks the same whether you view it in New York, Tokyo, or Madrid. That system is the partnership between Unicode and UTF-8.

This post will trace the evolution of character encoding, explaining why older systems failed and how UTF-8 rose to become the dominant, future-proof solution for global communication.

The Fundamental Problem of Encoding

Before diving into Unicode, we must understand the core challenge: Character Encoding.

Computers fundamentally only understand bits —sequences of 1s and 0s. Character encoding is the necessary process of transforming human-readable strings (text) into these bits so the computer can process, store, and transmit them.

We can look at a simpler, pre-computer example: Morse code. Invented around 1837, Morse code used only two symbols (short and long signals) to encode the entire English alphabet (e.g., A is .- and E is .).

With computers, this process became automatized. The general flow for data exchange is always:

    Message -> Encoding -> Store/Send -> Decoding -> Message

The Failure of Early Standards (ASCII)

To automate encoding in the early days of computing, standardized methods were required.

The Introduction of ASCII (1963)

One of the early standards created around 1963 was ASCII (American Standard Code for Information Interchange). ASCII worked by associating each character with a decimal number, which was then converted into binary. For example, the letter ‘A’ is 65 in ASCII, stored as 1000001 (or 01000001 in an 8-bit system).

The Incompatibility Crisis

The major limitation of ASCII was its size: it only covered 127 or 128 characters (primarily the English alphabet and common symbols). . Because of this limitation, ASCII had a problem if non-English characters, like the French ‘ç’ or the Japanese ‘大’, needed to be added. In response, people created their own extended encoding systems throughout the late 1960s to the 1980s. This fragmentation resulted in severe compatibility issues. When a file encoded with one system was interpreted using the wrong encoding system, the result was incomprehensible text, or “jibberish”

Unicode — The Universal Character Set (1991)

After years of struggling with incompatible encodings, a new standard was developed to unify character representation: Unicode , introduced in 1991.

The Goal: Unicode’s objective is to provide a unique number, called a code point, for every character , regardless of the platform, program, or language. This standardized approach made Unicode “the Rosetta Stone of Characters”.
The Scope: Unicode currently defines over 137,000 characters. This vast set includes:
- Non-Latin scripts (e.g., Chinese, Arabic, Japanese, Cyrillic).
- Symbols, mathematical notation, and currency signs.
- A wide range of emojis (e.g., 😀) and historical scripts.
Definition vs. Encoding: It is important to remember that Unicode defines the character and assigns its code point; it does not dictate how that code point is stored. That task belongs to the encoding system.

UTF-8 — The Dominant Encoding (1993)

UTF-8 (Unicode Transformation Format) was created in 1993 to efficiently store and transmit Unicode code points. It quickly gained popularity, becoming the dominant character encoding on the web by 1996. Today, more than 94% of websites use UTF-8.

The Key Advantages of UTF-8

Backward Compatibility with ASCII: This is a major reason for its success. The first 127 characters (the ASCII range) are encoded identically in UTF-8 and only require 1 byte. This means that older ASCII systems can still handle basic English text that is encoded in UTF-8.
Efficient Variable-Width Encoding: UTF-8 uses a variable-width scheme, meaning a character can take from 1 to 4 bytes. This optimizes storage because the most frequently used characters (Latin alphabet) use the fewest bytes.
Future-Proof Capacity: UTF-8 is designed to handle all existing and future Unicode values. The 4-byte template provides 21 available slots for bits, allowing it to store up to 2,097,152 values. This far exceeds the current capacity of the Unicode standard (around 1.1 million), ensuring that you won’t need to switch to another encoding system in the future to allocate new characters.
Robustness: UTF-8 is considered robust because it is self-synchronizing , which makes error detection and recovery easier during transmission or storage.

How the Variable-Width Encoding Works

UTF-8 uses byte templates to signal how many bytes a character occupies, depending on the code point’s value.

Byte Count	Code Point Range	Template Structure Start	Notes
1 Byte	Up to 127 ( ASCII )	Always starts with `0`	Used for basic English characters.
2 Bytes	Up to 2047	Starts with `110`	Used for many European characters (e.g., ‘À’).
3 Bytes	Beyond 2047	Starts with `1110`	Used when 11 bits are insufficient.
4 Bytes	Up to 21 bits of value	Starts with `11110`	Necessary for high-value characters like complex emojis (e.g., 🙂, which has 17 bits).

Handling Complex Unicode Characters

Unicode and UTF-8 also define how visually complex characters are represented digitally, often combining multiple unique code points into a single graphical unit.

Composite Emojis (Skin Tones): Some emojis that feature skin tone variations (e.g., ‘🖖🏾’) are represented internally in Unicode as a combination of two separate characters. When the computer sees these two characters placed together, it renders them as a single emoji with the skin tone applied.
Flag Emojis: Similarly, flag emojis (e.g., ‘🇦🇺’) are represented by a combination of two distinct abstract Unicode characters called “Regional Indicator Symbols”. When placed next to each other, the computer interprets the combination and displays the corresponding flag.

Conclusion

When working with any kind of text, it is crucial to remember that it is always tied to an associated encoding system. UTF-8’s ingenious design—combining efficiency, total Unicode coverage, and crucial backward compatibility with ASCII—has made it the essential standard for modern digital life. It is advisable to use modern encoding systems like UTF-8 to ensure maximum compatibility and avoid the need for future format switches.

Watch on youtube 👇

Deploy static site using netlify and zola

Neeraj Verma — Sun, 19 May 2024 09:24:00 +0000

Netlify is a popular platform for hosting static sites, and it integrates seamlessly with Zola, a fast and user-friendly static site generator. This article will guide you through deploying your Zola site to Netlify, giving you a quick and easy way to share your creation with the world.

Setting Up Your Zola Project

Before diving into Netlify, ensure you have a Zola project ready. If you’re new to Zola, head over to their official documentation to get started with creating a new project and populating it with content.

Initializing and setting up site in local

To initialize the site in local you can run the following:

$ zola init local-site

The initializer command will ask few question. Configure these as per your requirement.

> What is the URL of your site? (https://example.com):
> Do you want to enable Sass compilation? [Y/n]:
> Do you want to enable syntax highlighting? [y/N]:
> Do you want to build a search index of the content? [y/N]:

Once inside the project directory cd local-site. Run the following command to build and run your site in local.

$ zola build
$ zola serve

Output of above command would be like below:

Building site...
Checking all internal links with anchors.
> Successfully checked 0 internal link(s) with anchors.
-> Creating 0 pages (0 orphan) and 0 sections
Done in 16ms.

Listening for changes in /home/<username>/<project>/local-site/{config.toml,content,sass,static,templates}
Press Ctrl+C to stop

Web server is available at http://127.0.0.1:1025

If everything went well. You will be able to access your static site on the above mentioned address i.e http://127.0.0.1:1025.

Browsing Zola themes

You may visit the Zola Themes page to browse and choose a suitable theme for your website. Detailed configuration instructions for each theme can be found on the respective themes page. For this article, we will be using the theme “Boring” as an example.

Installing theme

To install theme run the following command from your project directory.

git init
git submodule add https://github.com/ssiyad/boring themes/boring

Build CSS

cd themes/boring
yarn install --frozen-lockfile
yarn build

Copy following theme files to root project directory

1. themes/boring/static/
2. themes/boring/templates/
3. themes/boring/css/
4. themes/boring/content/

Run site in local

Run following command from root project directory.

zola serve

Netlify deployment

Move site to Git provider: Push your site to any of your preferred Git providers like Github, Gitlab, and Bitbucket.
Netlify Account: If you don’t have one already, create a free Netlify account https://www.netlify.com/.
New Site: Log in to Netlify and click on “New site” to create a new project.
Connect to Git: Netlify offers integration with various Git providers like GitHub, GitLab, and Bitbucket. Choose your preferred provider and connect Netlify to your Zola project repository.
Deployment Configuration (Optional): While Netlify can automatically detect Zola projects, you can create a netlify.toml file in your project’s root for more control. This file allows you to specify the Zola version and other build configurations https://www.getzola.org/documentation/deployment/netlify/. The basic configuration looks like this:

[build]
publish = "public"
command = "zola build"

[build.environment]
ZOLA_VERSION = "your_desired_zola_version" # Optional: Specify Zola version

Deployment: Once the connection with your Git repository is established, Netlify will monitor your project for changes. Any push to your main branch (usually named “main” or “master”) will trigger Netlify to rebuild your site using the zola build command and deploy the generated content in the public directory.
Custom domain: Go to domain managenent section for your site on Netlify to setup your custom domain.

Previewing and Going Live

Netlify provides a preview URL for your site during development. This lets you see how changes look before they go live. Once you’re happy with your deployment, Netlify offers a simple toggle to publish your site to a custom domain name or a free Netlify subdomain.

With these steps, your Zola site should be up and running on Netlify! Netlify offers additional features like environment variables, build plugins, and custom headers, allowing you to further customize your deployment process. Refer to the official Netlify documentation for a deeper dive into these functionalities https://docs.netlify.com/site-deploys/create-deploys/.