DEV Community

I Built a Pneumonia Detection AI on My MacBook — Here's Exactly How It Works

nandhu_sauce — Fri, 24 Apr 2026 11:37:31 +0000

I just finished building a deep learning system that identifies pneumonia from chest X-rays with 96% accuracy and an AUC-ROC of 0.99. I ran the entire training process on my MacBook Pro M5 using the GPU acceleration provided by Apple's Metal Performance Shaders (MPS). This project wasn't about complex math; it was about using transfer learning to turn a consumer laptop into a medical diagnostic tool. Understanding how to handle messy data and verify what an AI is actually "seeing" is more important than having a massive server room.

WHAT I ACTUALLY BUILT

At its core, I built a computer program that acts like a specialized set of eyes for doctors. You feed it a digital chest X-ray image, and in less than a second, it tells you whether it sees signs of pneumonia or a normal, healthy lung. It doesn't just guess; it provides a confidence percentage for its decision. The system is designed to catch cases that might be subtle to the human eye, acting as a second pair of eyes to reduce diagnostic errors.

THE DATASET PROBLEM NOBODY MENTIONS

When I first looked at the data, I found a massive problem: class imbalance. The training set had 1,341 "Normal" images but a whopping 3,875 "Pneumonia" images. If I had trained the model as-is, it would have quickly learned that "guessing pneumonia every time" results in 74% accuracy without actually learning a single thing about lungs. This is a common trap in AI where a high accuracy score hides a completely useless model.

To fix this, I used two specific techniques to level the playing field. First, I implemented a WeightedRandomSampler, which you can think of as "photocopying rare examples." It ensures that during training, the model sees the "Normal" images more frequently so it doesn't forget what a healthy lung looks like. Second, I added class weights to the loss function—essentially a "bigger penalty for missing rare cases." If the model misclassifies a "Normal" lung as pneumonia, the error signal it receives is mathematically amplified, forcing it to pay closer attention to those specific patterns.

WHY I DIDN'T TRAIN FROM SCRATCH

I didn't start with a blank slate. Instead, I used a technique called transfer learning with an architecture known as ResNet-18. Think of it like this: a radiologist who already knows what edges, textures, and shapes look like doesn't need to relearn basic vision from scratch. They already have the "visual foundation" from years of looking at the world; they just need to learn what sick lungs look like specifically. ResNet-18 comes pre-trained on millions of everyday images (like dogs, cars, and trees), so it already understands how to detect lines and textures.

I used a two-phase training strategy to refine this pre-existing knowledge. In Phase 1 (Epochs 1-5), I froze most of the model and only trained the very last layer. This allowed the model to get a "feel" for the new medical data without overwriting its basic visual skills. In Phase 2 (Epochs 6-20), I unfroze everything and used a tiny learning rate to fine-tune the entire network. At the start of Phase 2, I saw a temporary spike in the loss curve. This is normal and expected—it's the mathematical equivalent of the model being slightly "confused" as it starts adjusting its deep-seated visual patterns to the nuances of X-ray tissue.

CAN YOU TRUST IT? GRAD-CAM EXPLAINABILITY

A 96% accurate AI is useless if it's a "black box" that you can't verify. In medical AI, you have to know why a decision was made. I implemented Grad-CAM (Gradient-weighted Class Activation Mapping), which is a tool that "shows you which pixels the model was looking at when it made its decision." Without this, a model might achieve 99% accuracy just by learning that images with a certain hospital's patient ID label in the corner are usually the pneumonia cases.

When I ran Grad-CAM on my results, the heatmaps were revealing. For pneumonia cases, the "heat" (red and yellow zones) was concentrated directly on the lung tissue where opacities usually appear. For normal cases, the focus was much more diffuse across the entire chest cavity. This gave me the confidence that the model was actually learning medical features, not just memorizing background noise or image artifacts.

THE RESULTS

After 20 epochs and about 45 minutes of training on my MacBook, here is how the system performed on the 624 images in the test set:

Metric	Score
Test Accuracy	96%
AUC-ROC	0.99
NORMAL F1	0.94
PNEUMONIA F1	0.96
False Negatives	15/390
False Positives	13/234

Let's break these down into plain English. Test Accuracy means the model was right 96 times out of 100 overall. AUC-ROC measures how well the model can distinguish between the two classes across different confidence levels; 0.99 is nearly perfect separation. F1 Score is a balanced average of precision (not flagging healthy people as sick) and recall (not missing sick people).

Most importantly, we have to look at the 15 missed pneumonia cases (False Negatives). In a clinical context, missing a sick patient is far worse than accidentally flagging a healthy one. This is why "Recall" matters more than "Accuracy" in medical AI. While 15 misses out of 390 is low, it highlights that this system is a diagnostic assistant, not a replacement for a human doctor who would catch those edge cases.

WHAT I LEARNED

This project taught me a few genuine technical lessons that go beyond the usual tutorials:

The Validation Set Trap: The original dataset only had 16 images in the validation folder. This made the validation accuracy bounce around wildly and become meaningless during training. You need a representative validation set to know if your model is actually improving.
Watch the Loss, Not the Accuracy: Accuracy is a "lagging indicator." The loss curve tells you the "quality" of the model's learning. If the loss is still going down but accuracy is flat, you're still making progress.
Grad-CAM is Mandatory: For medical AI, explainability isn't a "nice to have." It's the difference between a useful tool and a legal liability. If you can't see the heatmaps, you shouldn't trust the predictions.
Apple Silicon is Ready: Training this on MPS (Metal Performance Shaders) was surprisingly fast. For this size of workload, you don't need a dedicated Linux server with a massive GPU; a modern MacBook Pro handles it in under an hour.

WHAT'S NEXT

I'm not finished with this system yet. My next steps are specific:

Fix the Validation Set: I'm going to move about 500 images from the training set into the validation set to get more reliable feedback during training.
Try DenseNet-121: This architecture is the current gold standard in chest X-ray research papers because of how it handles feature reuse.
Build a Web UI: I want to use Streamlit to create a simple drag-and-drop interface so anyone can test the model without looking at code.
Kaggle Notebook: I've already published a self-contained version of this project as a Kaggle notebook for the community to play with.

CLOSING

This project demonstrated that you don't need a supercomputer to build high-performing medical AI. By using transfer learning and being smart about how you handle imbalanced data, you can achieve professional-grade results on consumer hardware. It's a testament to how accessible deep learning has become, provided you focus on the data and the "why" behind the predictions.

Disclaimer: This model is for educational purposes only and is not intended for clinical use.

View the full notebook on Kaggle
View the code on GitHub

Mastering Template Literals in JavaScript: Say Goodbye to String Concatenation Nightmares

Ritam Saha — Fri, 24 Apr 2026 11:28:32 +0000

Introduction

Imagine you're building a dynamic dashboard for your full-stack app. You need to greet users like "Welcome back, Ritam! Your last login was on April 24, 2026, at 4:28 PM IST." In the old days, you'd glue strings together with plus signs, escaping quotes, managing calculated spaces and praying for no typos. It quickly turns into a headache—unreadable for devs also, error-prone, and a maintenance nightmare.
Now enters template literals, JavaScript's elegant solution since ES6. They make string building feel natural, boosting your code's readability and productivity. Let's dive in and see why they're a game-changer.

The Pain of Traditional String Concatenation

Before template literals, we relied on concatenation with + or arrays joined by join(''). It works, but it's clunky and wasn't a good experience for the developers.

Example: Old-school greeting


const name = 'Ritam';
const lastLogin = 'April 24, 2026, 4:28 PM IST';
const greeting = 'Welcome back, ' + name + '! Your last login was on ' + lastLogin + '.';
// Output: "Welcome back, Ritam! Your last login was on April 24, 2026, 4:28 PM IST."

Problems abound:

Readability suffers as strings grow;
spotting variables amid quotes is tough.
Easy to miss spaces or add extra ones (e.g., 'back,' + name vs. 'back, ' + name).
No native multi-line support—forces ugly escape-sequence \n or + across lines.
Debugging? Typos in long chains are brutal.

This scales poorly in real apps, like API responses or HTML generation.

Template Literal Syntax: Backticks Unlock the Magic

Template literals use backticks (`) instead of single (') or double (") quotes. Key features:

Interpolation: Embed expressions with ${expression}.
Multi-line: Spans lines without escapes.
Expression support: ${} evaluates anything—variables, functions, math.

const greeting = Hello, world!; // Simple string

Embedding Variables: String Interpolation Made Simple

Interpolate with ${}—JavaScript evaluates and inserts the result/expression. It's dynamic and concise.

const name = 'Ritam';
const city = 'Kolkata';
const greeting = Welcome back to your dashboard, ${name} from ${city}!;

// Output: "Welcome back to your dashboard, Ritam from Kolkata!"

Technical Breakdown:

${name} calls toString() on name implicitly.
Even supports complex expressions: ${name.toUpperCase()} or ${2 + 2} yields "RITAM" or "4".

Compare with concatenation:

const oldGreeting = 'Welcome back to your dashboard, ' + name + ' from ' + city + '!';
// Template literal (clean and readable)
const newGreeting = Welcome back to your dashboard, ${name} from ${city}!;

Template literals win on readability—scan for ${} to spot variables instantly.

Multi-Line Strings: No More Escapes

Need formatted text, like emails or SQL? Backticks handle newlines naturally.

const user = 'Ritam';
const emailBody = `
Dear ${user},

Your portfolio project deployed successfully on Vercel.
Next steps:

Review PR on GitHub
Test Node.js backend

Happy coding!
Team
`;
// Output preserves exact formatting, including indents.

Use Cases in Modern JavaScript

Template literals shine in full-stack dev:

API Responses: const response = User ${userId} logged in at ${new Date().toISOString()};
HTML Templating (pre-React): Hello, ${name}! (sanitize for security).
Tagged Templates (advanced): Libraries like styled-components use them for dynamicity, e.g., styled.divHello ${name}.
Debug Logs: console.log(Error in ${functionName}: ${error.message});
SQL Builders: SELECT * FROM users WHERE id = ${userId} (use params to prevent injection).

Conclusion: Level Up Your JS Strings Today

Template literals transform string handling from a chore to a joy—readable, flexible, and modern. Ditch concatenation; embrace backticks for cleaner code that scales with your projects. Next time you're building that portfolio app or prepping for interviews, reach for ${}. Your future self (and teammates reviewing your PRs) will thank you.

I Built a Private, Local-First AI Assistant with Flask

Ramesses_2 — Fri, 24 Apr 2026 11:23:07 +0000

The Goal: I wanted an AI assistant that doesn't save my logs to the cloud and utilize my hardware.

Though it's quite slow as of now, I believe with further optimization and advancement in local silicon, edge AI would inevitably become the next big thing in the very near future.

The Tech: I used Flask, TinyLlama, and Python-dotenv for security. I also took the help of Claude and Copilot wherever the code was repetitive and well beyond my current grasp on Python.
I am a college freshman (about to become a sophomore), but I seek merciless feedbacks. Do provide me honest feedbacks about this project.

Github Repository

sounak1410 / Web-Based-Edge-AI-

A personalized Small Language Model that runs locally on your device's hardware without having to access the internet or the cloud

Y Assistant

A privacy-focussed local AI chatbot powered by TinyLlama

Y is a lightweight web-based AI assistant designed to run entirely on your local machine. It features a custom architecture demo, a secure login system, and per-session memory, ensuring that your conversations stay private and contextual. Created by S (My pseudonymn).

Features

No data leaves your machine. It runs on TinyLlama 1.1B.
Contextual Memory: Remembers the last 10 messages for a natural conversation flow.
Secure Access: Protected by a customizable password system.
Privacy-First: No permanent logs are stored; session data is cleared on request.
Architecture Demo: Includes a raw GPT-2 initialization script to show how LLMs are structured.

Installation

Install my-project with npm

  # Clone the repository
git clone https://github.com/sounak1410/Web-Based-Edge-AI-.git

# Enter the directory
cd Web-Based-Edge-AI-

# Install dependencies
pip install -r requirements.txt

# Run the application
python Edge.py

Chatting with Y

Open your browser to http://127.0.0.1:5000.
Enter the…

View on GitHub

Designing Go APIs That Don’t Age Badly

Chiman Jain — Fri, 24 Apr 2026 11:20:56 +0000

When building APIs in Go, it’s easy to get caught up in the rush to ship. You create an elegant endpoint, document it, and call it a day. But as your service evolves and your user base grows, what once seemed like a simple, clean API can quickly turn into a maintenance nightmare. If you don’t consider the long-term design of your Go APIs, you may find yourself with an API that becomes difficult to maintain, fragile, and hard to scale.

In this post, we’ll cover some essential strategies for designing Go APIs that can stand the test of time. These include versioning, avoiding breaking changes, and mindful interface design.

The Problem with API Design in Go

Go encourages simplicity and directness, but when it comes to managing evolving APIs, the language itself doesn’t impose conventions for API stability. The challenge for Go developers is to strike a balance between flexibility and longevity.

A bad decision made early on in API design can result in breaking changes that ripple through your application, potentially causing months of work for your team and frustration for consumers. But with careful planning and foresight, you can design APIs that are robust, adaptable, and flexible without introducing future headaches.

1. Versioning Your Go APIs Don’t Ignore It

When building an API, versioning should be a core consideration from day one. Even if you don’t plan to make major changes now, assume that you will need to, and plan accordingly.

Why Versioning Matters

Maintaining backward compatibility: Versioning allows you to introduce changes to your API while ensuring that existing clients can continue to work without disruption.
Controlled deprecation: You can signal to consumers which features or endpoints are deprecated and provide a migration path.
Separation of concerns: It allows your codebase to evolve while clearly distinguishing between stable and experimental functionality.

Versioning Strategies

URI Versioning (e.g., /v1/resource or /v2/resource):
- Pros: Simple to implement and understand. It’s immediately obvious which version of the API a client is calling.
- Cons: If not managed carefully, it can lead to API version bloat, where you have to maintain multiple versions for a long time.
- Best for: Major version changes, or when you need to make breaking changes that require a new major version of the API.
Header-based Versioning (e.g., X-API-Version):
- Pros: Cleaner URLs, and you can keep versioning entirely out of the URL path.
- Cons: Requires consumers to be aware of and set the correct headers. Not as intuitive as URI versioning.
- Best for: Small, non-breaking changes that do not require creating an entirely new version of the API.
Semantic Versioning (e.g., v1.0.0, v1.1.0):
- Pros: You can convey the type of changes made (major, minor, patch) through version numbers. Very clear for both developers and consumers.
- Cons: Slightly more complex than simple URI-based versioning.
- Best for: APIs that evolve over time and need to clearly communicate how changes affect consumers.

Versioning Tip

Start versioning early. Even if your API doesn’t seem to need versioning now, create a versioning scheme from the beginning. It’s easier to version early than to retroactively patch an unversioned API.

2. Avoiding Breaking Changes A Delicate Balance

In Go, backward compatibility is crucial, but sometimes breaking changes are inevitable as your API evolves. The goal is to minimize these changes, especially for clients relying on your service.

Common API Changes That Cause Breakage

Removing or renaming fields: Clients may rely on specific fields being present, even if they aren’t always used.
Changing return types: A seemingly small type change can break client code that relies on the original type.
Changing HTTP methods: A switch from POST to PUT, or modifying an endpoint’s expected behavior, can cause unexpected failures.
Introducing new required fields: If your API starts requiring new fields that weren’t previously required, existing clients may break.

Best Practices to Avoid Breaking Changes

Deprecate, Don’t Delete

Rather than removing or renaming an endpoint, deprecate it and introduce a new one. Provide clear documentation about the deprecation, give consumers plenty of time to migrate, and offer new functionality alongside old functionality.
Use Optional Fields

When adding new fields, make them optional and only introduce required fields in new versions of the API. This ensures existing consumers won’t be broken by your changes.
Don’t Change Existing Behaviors

If you change how an endpoint behaves, try to do so in a way that’s backward compatible. For example, you could add an optional query parameter to change the behavior, rather than altering the behavior entirely.
Graceful Error Handling

When an API change occurs, ensure that you handle errors gracefully. Provide clear, actionable error messages that guide users toward the changes they need to make in their client applications.

3. Interface Design Pitfalls Avoiding Tomorrow’s Headaches

In Go, interfaces are incredibly powerful, but they come with a lot of room for misuse. Designing APIs with poorly thought-out interfaces can lead to rigid, fragile systems that break easily when your application evolves.

Common Pitfalls in Interface Design

Overuse of Interfaces

Go interfaces are great, but they shouldn’t be overused. Often, developers fall into the trap of defining interfaces for every little component in their code. This can lead to unnecessary complexity and makes it harder to refactor in the future.
Inconsistent Method Sets

An interface should have a well-defined, coherent set of methods. If you change the method set too frequently or make the methods too vague, you’ll find it difficult to maintain consistency across your codebase.
Interface Pollution

Avoid creating interfaces that are too general and try to do too much. Each interface should have a clear, focused responsibility.
Breaking Changes in Interfaces

Removing or changing methods in an interface is a breaking change. Instead, prefer adding methods and allowing optional extensions in your interfaces.

Best Practices for Interface Design

Design Interfaces for Use, Not for Flexibility

Focus on designing interfaces that actually solve problems for users of your API. Don’t make interfaces more general than they need to be just to add flexibility.
Make Interfaces Small and Focused

Keep interfaces small and focused on one responsibility. The more focused the interface, the easier it is to maintain and evolve without breaking things.
Prefer Composition Over Inheritance

Use struct embedding (composition) rather than inheritance (interface embedding) to compose behavior across different types. This avoids complex hierarchies and allows for better flexibility in adding new functionality without breaking existing code.
Avoid Tight Coupling

Make sure your API is loosely coupled. This can be achieved by:
- Using dependency injection where necessary
- Avoiding direct dependencies on other packages in your interfaces
- Keeping interfaces simple and allowing different implementations

Final Thoughts: Future-Proofing Your Go API

API design isn’t just about making something that works today it’s about making something that will still be usable, maintainable, and extensible tomorrow. In Go, the key to future-proofing your APIs is thinking ahead versioning early, avoiding breaking changes, and being mindful of interface design. With these strategies, you’ll ensure that your Go APIs not only work in the present but can also adapt to changes as your application and team evolve.

If you’re planning a major API refactor or starting a new project, take the time to implement these principles early. By doing so, you’ll save yourself (and your team) from much greater pain later down the road.

Remember: Good design is not just about elegance today it’s about resilience over time.

React Email 6.0, Vercel got hacked, Prevent flash before hydration, Logging in Next.js, shader-lab, TypeScript 7.0, nextmap

Erfan Ebrahimnia — Fri, 24 Apr 2026 11:20:30 +0000

React Email 6.0

The highlight of this release is an open-source email editor that outputs inbox-ready HTML. It has a composable API for building custom blocks like image uploaders or social embeds. Also new: a unified single package for all components and a fresh set of templates for auth and e-commerce flows

Vercel April 2026 security incident

Vercel disclosed a security incident where an attacker compromised a third-party AI tool (Context.ai) used by an employee, gaining access to some internal systems and non-sensitive environment variables. No npm packages were affected. Vercel recommends rotating credentials, enabling 2FA, and reviewing activity logs

⚡️ Sponsor: Clerk

Clerk CLI: manage auth from your terminal

The new Clerk CLI detects your framework and gets auth ready to configure. Run clerk init to scaffold, clerk config to manage sign-in methods, redirects, and session policies in code, or clerk api to query users and orgs. Try it.

📙 Articles / Tutorials / News

New Docs: How to prevent flash before hydration

New docs explaining how to avoid the visible flicker when things like dates, themes, or localStorage values differ between server and client

If You Can't See the Boundary, You Can't Reason About the System

We featured the RSC Boundary package in a previous issue. This article from its creator explains the problem it solves: When working with React Server Components, you often have to guess where the server/client split is by reading 'use client' directives and tracing imports. RSC Boundary removes that guesswork. It's a dev-only overlay that highlights which parts of your page are server-rendered and which are client components, giving you a live visual map

Next.js 16 Migration Guide: Everything That Breaks (And How to Fix It)

A thorough, hands-on migration guide covering every breaking change in Next.js 16 and how to deal with it

Logging in Next.js with LogLayer

Next.js logs can get messy across different runtimes. This post shows how to fix that with one shared logger using LogLayer, console interception in instrumentation.ts, and structured output with Pino for production

📦 Projects / Packages / Tools

@basementstudio/shader-lab

A visual tool and React runtime for creating layered shader compositions. Render directly in your app, use them as Three.js textures, or apply built-in effects like ASCII, CRT, dithering, and pixel sorting as postprocessing over your own 3D scenes. Fully open source

nextmap

A CLI tool that scans your Next.js project and shows every route as an interactive graph in your browser. It picks up pages, API routes, middleware, and HTTP methods

Animata

Handcrafted interaction animations and visual effects built with Tailwind CSS and Framer Motion. Works like shadcn/ui

Announcing TypeScript 7.0 Beta

The first beta release of TypeScript 7.0 is here, and it's a big deal. The compiler has been completely rewritten in Go, making it around 10x faster than TypeScript 6.0. It now supports parallel type-checking and parallel project builds out of the box. Despite being a beta, the team says it's stable enough for everyday use

⚡️ Sponsor: Expo

How to go from Web to Native with React

Everything that web devs need to know about building their first mobile app - You already know React. With Expo, you can use that knowledge to build fully native apps for iOS and Android without starting over or learning new tools

🌈 Related

Building a UI Without Breakpoints

Modern interfaces are component-first, but most responsive CSS is still viewport-first. This article bridges that gap with four methods: intrinsic layouts using auto-fit and minmax(), fluid scaling with clamp(), container units for sizing relative to a component's actual space, and container queries for true structural changes

10 React tips I wish someone had told me before I mass-produced bugs

Lessons learned from production bugs and code reviews. Includes tips like replacing multiple useState calls with useReducer, keeping state close to where it's used, using key to reset components, and choosing Compound Components over prop-heavy APIs

A TypeScript Class-Based WebSocket Library for React

Explaining a different approach to WebSockets in React. Instead of putting everything in hooks, the heavy lifting lives in TypeScript classes

AI-Generated UI Is Inaccessible by Default

Breaks down exactly why LLMs produce inaccessible code and presents a practical five-layer fix: prompt constraints, static analysis with eslint-plugin-jsx-a11y, runtime testing with axe-core, CI enforcement via GitHub Actions, and using accessible component libraries like Headless UI, Radix, or React Aria

AI Portfolio Generator for Developers: Stop Overthinking It and Ship the Thing in 2026

Maya Bayers — Fri, 24 Apr 2026 11:19:21 +0000

You have built production apps. You have debugged systems at 2am. You have shipped features that thousands of people use.

And yet your portfolio is either a half-finished Next.js site you started six months ago, a GitHub profile with a decent README, or something you keep meaning to update when you have more time.

You are not alone. Developer portfolios are one of the most consistently delayed personal projects in the industry — and the reason is almost never a lack of good work to show.

Why developer portfolios stall

The technical part is not the problem. Most developers could build a portfolio site in a weekend. The problem is the content layer.

Writing about your own work is genuinely hard. Translating what you built, why you built it that way, and why it mattered into language that a non-technical hiring manager or potential client can understand — without dumbing it down so much it loses meaning — is a different skill set than the one you use every day.

That is exactly where AI helps most in 2026.

What AI actually does well for a developer portfolio

Think of AI as a drafting tool for the content layer — not a replacement for your technical judgment.

Bio writing. Give AI a few bullet points about your stack, your focus, and your background. It will return a first draft you can edit from. That is infinitely faster than starting from a blank text file.

Project summarizing. Paste in your README, your commit history summary, or rough notes about a project. AI can turn that into a readable three to five sentence portfolio description that explains the problem, your approach, and the outcome in plain language.

Section structure. Not sure whether to lead with projects or stack? AI can suggest a logical page structure based on your experience level and the kind of role you are targeting.

Headline and CTA drafting. The copy around your work — the homepage headline, the contact section, the about page intro — is where most developer portfolios feel weak. AI handles first drafts of these quickly.

FAQ and stack descriptions. Short, scannable blocks that answer the questions a recruiter or client actually has. AI drafts these well from your input.

What you must write yourself

This is where most AI-assisted developer portfolios fall apart.

Do not let AI fully own the technical substance of your portfolio. Specifically:

What you actually built and what technical decisions you made. The tradeoffs you navigated — why you chose PostgreSQL over MongoDB, why you went with a monolith instead of microservices, what you would do differently now. The specific business or user problem your code solved and why it mattered. Performance improvements, scale numbers, or technical outcomes you can actually verify. What your real contribution was on collaborative or team projects.

A technical hiring manager reading your portfolio is not just evaluating your stack. They are evaluating your thinking. They want to know whether you understand why the decisions you made were the right ones for the context — and whether you can communicate that clearly.

AI cannot fake depth of technical reasoning convincingly. Only you can write that part well.

Best tools for a developer portfolio in 2026

Unicorn Platform is the strongest no-code option for developers who want a clean, professional portfolio site live quickly without it becoming another side project. The editing is fast, the section structure is practical, and updating it does not require touching a codebase every time something changes. Strong for developers who bill hourly or run client-facing work and need a real site — not just a GitHub profile.

Lovable is worth considering for developers comfortable with AI-generated site direction who want to move from concept to published draft quickly. Useful for testing portfolio structures before committing to a final build.

Figma Make is less commonly the first choice for developers but worth knowing if the role you are targeting has a significant frontend, product, or design component — or if you want stronger layout control for a design-led portfolio structure.

Gamma is a strong fit for developers moving into technical leadership, product, or engineering management roles where the portfolio needs to demonstrate strategic thinking and communication as much as technical execution. Narrative-driven structure works well here.

Canva is a practical fallback for developers who want something clean and professional without any design decision overhead. Less suited to deep multi-page structures but useful for a lightweight proof-of-work page.

Portfolio structure that actually works for developers

Keep it simple. The structure should make it easy for someone to understand who you are, what you build, and why your projects mattered — in under two minutes.

A strong developer portfolio structure in 2026:

Hero section — your role, focus area, and a one to two sentence positioning statement. Not a list of technologies. Not "passionate developer." Something specific like "I build performant React applications for early-stage SaaS products" or "I work on backend infrastructure for high-traffic consumer apps."

Featured projects — three to five projects maximum. For each one: the problem it solved, your specific contribution, the stack, and a measurable outcome if possible. Link to a live demo or GitHub repo where relevant.

Stack or capability block — optional but useful if the role you are targeting values specific technical expertise. Keep it scannable and specific. Avoid listing every technology you have ever touched.
About section — short personal context. Why you got into development, what kind of problems you find interesting, what you are working on or learning now. Two to three sentences is enough.

Contact CTA — make it obvious and frictionless. One clear action. No contact form with twelve fields.
That is the complete structure. Resist the temptation to add more sections because more content feels like more effort.

Prompts developers can actually use

For your hero section: "Write a two-sentence homepage positioning statement for a frontend developer with four years of experience building React and TypeScript applications for SaaS products. Focus on clean UI, performance, and shipping user-facing features. Keep it specific and avoid generic developer clichés."

For a project description: "Write a four-sentence portfolio project description for a developer who built a real-time collaborative document editor using React, Socket.io, and Node.js. Explain the technical challenge, the key architectural decisions, the stack, and the outcome. Keep it readable for a non-technical audience without losing technical credibility."

For your about section: "Write a short about section for a full-stack developer portfolio. Background is three years building internal tools and dashboards for fintech startups. Interested in developer experience, API design, and building things that non-technical teams can actually use. Keep it human and specific."

For a stack block: "Write a short technical capabilities section for a backend developer portfolio. Core stack is Python, FastAPI, PostgreSQL, and AWS. Keep it scannable, specific, and focused on what I actually use in production — not a comprehensive list of everything I have touched."

A workflow that gets your developer portfolio shipped

The reason most developer portfolios never launch is scope. The project feels too open-ended, the content feels too hard to write, and a client project or interesting open source problem always takes priority.

This workflow keeps the scope manageable and gets you to a published first version:

Step one. Choose three to five projects you are genuinely proud of — ideally ones that represent the kind of work you want more of. Not necessarily your most technically complex work. The work that is most relevant to the roles or clients you are targeting.

Step two. For each project, write three honest bullet points in plain language: the problem it solved, what you specifically built or contributed, and the real outcome. Do not worry about polish at this stage.

Step three. Feed those bullets into AI and ask it to turn them into a readable project description. Review the output carefully. Add back the technical specifics. Remove anything that overstates your role or claims outcomes you cannot verify.

Step four. Use AI to draft your bio and hero section from your background and focus. Rewrite until it sounds like you actually said it — not like a job description written by someone else.

Step five. Choose the simplest site structure that answers the questions your target audience actually has. Resist adding sections because they look impressive. Every section should earn its place.

Step six. Launch the first version. A live portfolio that is honest and specific is always more valuable than a perfect one that never ships.

Step seven. Update it when you finish something worth adding. Treat it like a living document — not a project you complete once and forget.

On domain and personal brand

If you are serious about building a professional presence in 2026, your domain and broader digital footprint matter more than most developers give them credit for. A well-chosen personal domain supports discoverability, signals professionalism, and gives you a stable home for your work as your career evolves.

This guide on AI-assisted domain naming strategy for 2026 is worth reading before you finalize your online setup — especially if you are thinking about personal branding alongside your portfolio.

The bottom line

AI is one of the most useful tools available for developer portfolio building in 2026. It solves the content layer problem — the part that actually blocks most developers from shipping — without requiring you to become a professional copywriter.

But the portfolio that gets you the interviews, the freelance clients, or the role you want is still the one that demonstrates real technical thinking. Honest project scope. Specific outcomes. A voice that sounds like a person with genuine opinions about how software should be built.

Use AI to draft faster. Write the technical substance yourself. Ship the first version.

Your GitHub profile is not a portfolio. A portfolio is a portfolio. Ship it.

How SNF Detects C2 Beacons on Air-Gapped Networks Without Ever Touching the Internet

Snf Labs — Fri, 24 Apr 2026 11:18:08 +0000

How SNF Detects C2 Beacons on Air-Gapped Networks Without Ever Touching the Internet

Most threat detection tools phone home. They pull threat feeds, push telemetry, verify licenses, or at minimum require a DNS resolver to function. That assumption is baked so deep into modern NDR that nobody questions it anymore.

SNF questions it.

SNF (Shadow Network Fingerprinting) is a passive network intelligence engine written entirely in Rust. It was designed from day one for environments where outbound connectivity is not just unavailable but prohibited: air-gapped defense networks, nuclear infrastructure, industrial control systems, classified SOCs.

The architecture enforces this. There are no configuration flags to disable telemetry, no license server to bypass, no optional cloud sync to turn off. The binary makes zero network calls. Ever. If you audit the source, you will not find a single outbound socket.

What SNF Actually Does

SNF captures raw packets passively, reconstructs TCP/UDP flows, and runs them through 14 deterministic protocol analyzers in a fixed order:

DNS, TLS, HTTP/1.1, HTTP/2, QUIC, DHCP, ICMP, SMB, mDNS, ICS, Enterprise, Discovery, DoH, and DoT.

On top of that it fingerprints TLS sessions using JA3 and JA4, detects C2 beacon patterns by analyzing packet timing and jitter, catches DGA domains through statistical entropy analysis, identifies DNS tunnels by payload size and query frequency, and covers the full ICS/SCADA protocol suite including Modbus, S7comm, EtherNet-IP, PROFINET, and DNP3.

Everything it finds gets emitted as structured NDJSON with a deterministic guarantee: run the same PCAP with the same config on the same version and you get bit-identical output, verified by SHA-256. This matters in forensic and legal contexts where reproducibility is not optional.

Here is SNF running against a real Emotet epoch 3 + Trickbot infection PCAP. No internet connection. No threat feed pulled at runtime.

23 IOC hits. 52 threat matches. JA3 fingerprinting attributed the TLS session directly to the Emotet/Trickbot loader. The stealth detector flagged three external IPs for portscan, tunnel, and exfil activity simultaneously. A DGA candidate scored 85 on a .onion domain.

Parse errors: 0. Capture errors: 0.

Why Determinism Matters

Most tools produce slightly different output across runs because of timing, threading, or probabilistic components. SNF uses BTreeMap for all output so field ordering is always identical. It has a tamper-resistant monotonic session clock. It produces cryptographically signed evidence bundles that hold up in court.

Same dataset plus same config plus same version equals identical SHA-256 output. Every single time.

This is not a nice-to-have. In a DFIR investigation, in a government audit, or in a legal proceeding, output that changes between runs is inadmissible. SNF was built around this constraint from the first commit, not bolted on after.

Performance on Real Data

On the MAWI backbone dataset (14.9 million packets, a real-world traffic sample used by network researchers globally), SNF processes at roughly 155,000 packets per second on a single core, sustaining around 1.25 Gbps throughput. On a 4-core VM it scales to 2.3x that with multi-worker mode.

What You Actually Get Out of a Run

One command. One PCAP. SNF writes structured output automatically, split by category and timestamped to the session.

Every run produces flows, devices, DNS, TLS fingerprints, IOC hits, threat matches, and a full session report in both NDJSON and CSV. No post-processing scripts. No manual export. Ready for SIEM import or court submission as-is.

The Open-Core Layer

The capture layer, flow reconstruction engine, and protocol parsers are open source under Apache 2.0 as snf-core on GitHub. The intelligence layer covering behavioral detection, fingerprinting, stealth mode, graph analysis, evidence bundles, SIEM export, and the threat databases is proprietary.

If you work in DFIR, ICS security, or blue team work in regulated environments, the repo is worth a look. Contributions to the open-core layer are welcome.

Website: https://shadownf.com
GitHub: https://github.com/padigeltejas/snf-core
LinkedIn: https://www.linkedin.com/company/snflabs/

How to Encode Base64 in JavaScript Without Breaking Unicode

MOUSTAID Hamza — Fri, 24 Apr 2026 11:17:44 +0000

Base64 encoding is one of those small developer tasks that looks simple until you hit Unicode characters, files, APIs, or URL-safe formats.

In JavaScript, many tutorials show this:

btoa("Hello World");

And yes, it works.

But only for simple ASCII text.

Once you try to encode something like:

"Café 🚀"

you may run into errors or broken output.

In this guide, we’ll cover how Base64 encoding works in JavaScript, when btoa() is enough, when it is not, and how to encode text, Unicode, files, images, and URL-safe Base64 correctly.

You can also test examples quickly with EncodingBase64, a free browser-based Base64 encoder for text, files, images, URL-safe Base64, hex, and URL encoding.

What is Base64 encoding?

Base64 is a way to represent binary data using readable ASCII characters.

It is commonly used when binary data needs to travel through systems that expect text, such as:

APIs
JSON payloads
email attachments
HTML/CSS data URIs
authentication headers
embedded images
configuration files

For example:

Hello World

becomes:

SGVsbG8gV29ybGQ=

Base64 does not encrypt data. Anyone can decode it.

It only changes the representation of the data.

Basic Base64 encoding with btoa()

JavaScript includes a built-in function called btoa().

Example:

const text = "Hello World";
const encoded = btoa(text);

console.log(encoded);
// SGVsbG8gV29ybGQ=

To decode it back:

const decoded = atob(encoded);

console.log(decoded);
// Hello World

This is fine for basic ASCII strings.

But there is a problem.

The Unicode problem with btoa()

Try this:

const text = "Café 🚀";
const encoded = btoa(text);

console.log(encoded);

Depending on the environment, you may get an error like:

InvalidCharacterError

Why?

Because btoa() expects a binary string where each character is in the Latin-1 range. It does not directly support full Unicode text.

Modern apps often deal with:

accented characters
Arabic
French
Spanish
German
Portuguese
emojis
non-Latin scripts

So we need a safer method.

Unicode-safe Base64 encoding

Use TextEncoder to convert the string into UTF-8 bytes first.

function encodeBase64Unicode(text) {
  const bytes = new TextEncoder().encode(text);

  let binary = "";
  bytes.forEach((byte) => {
    binary += String.fromCharCode(byte);
  });

  return btoa(binary);
}

console.log(encodeBase64Unicode("Café 🚀"));
// Q2Fmw6kg8J+agA==

Now the Unicode string is safely converted to UTF-8 before Base64 encoding.

Unicode-safe Base64 decoding

To decode it back properly, use TextDecoder.

function decodeBase64Unicode(base64) {
  const binary = atob(base64);

  const bytes = Uint8Array.from(binary, (char) => {
    return char.charCodeAt(0);
  });

  return new TextDecoder().decode(bytes);
}

const encoded = encodeBase64Unicode("Café 🚀");
const decoded = decodeBase64Unicode(encoded);

console.log(decoded);
// Café 🚀

This is safer for real-world text.

Encoding a file to Base64 in JavaScript

For files, you can use FileReader.

Example with an HTML file input:

<input type="file" id="fileInput" />

const input = document.getElementById("fileInput");

input.addEventListener("change", () => {
  const file = input.files[0];

  if (!file) return;

  const reader = new FileReader();

  reader.onload = () => {
    console.log(reader.result);
  };

  reader.readAsDataURL(file);
});

The result will look like this:

data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAA...

This is called a data URI.

It includes:

data:[mime-type];base64,[base64-data]

For example:

data:image/png;base64,iVBORw0KGgo...

If you only want the raw Base64 part, remove everything before the comma:

const dataUrl = reader.result;
const rawBase64 = dataUrl.split(",")[1];

console.log(rawBase64);

Encoding an image to Base64

Images are one of the most common Base64 use cases.

You might encode images to Base64 when:

embedding a tiny icon in HTML
storing a small image in JSON
sending an image through an API
generating previews
creating CSS background images

Example HTML output:

<img src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAA..." alt="Example" />

Example CSS output:

.icon {
  background-image: url("data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAA...");
}

This is useful for small images.

But be careful: Base64 increases file size, so it is usually not ideal for large images.

For quick browser-based image conversion, EncodingBase64’s Image to Base64 tool can convert images into raw Base64, data URI, HTML, CSS, or Markdown formats.

What is URL-safe Base64?

Standard Base64 uses characters like:

+
/
=

These characters can be problematic in URLs.

URL-safe Base64 replaces:

+ with -
/ with _

Padding = may also be removed in some systems.

Example helper:

function toBase64Url(base64) {
  return base64
    .replace(/\+/g, "-")
    .replace(/\//g, "_")
    .replace(/=+$/g, "");
}

const encoded = encodeBase64Unicode("Hello World");
const urlSafe = toBase64Url(encoded);

console.log(urlSafe);
// SGVsbG8gV29ybGQ

To convert Base64URL back to standard Base64:

function fromBase64Url(base64Url) {
  let base64 = base64Url
    .replace(/-/g, "+")
    .replace(/_/g, "/");

  while (base64.length % 4 !== 0) {
    base64 += "=";
  }

  return base64;
}

Base64URL is commonly used in:

JWTs
URL tokens
authentication flows
compact identifiers
web-safe encoded data

Common Base64 encoding mistakes

1. Thinking Base64 is encryption

Base64 is not secure. It is reversible.

Do not use it to protect passwords, API keys, or private data.

2. Using btoa() directly with Unicode

This can break:

btoa("Café 🚀");

Use TextEncoder instead.

3. Using standard Base64 in URLs

Standard Base64 can contain +, /, and =. Use Base64URL when the value needs to go inside a URL.

4. Encoding large images unnecessarily

Base64 is usually better for small assets, not large files.

5. Forgetting the MIME type for images

For browser display, this:

iVBORw0KGgo...

may not be enough.

You often need:

data:image/png;base64,iVBORw0KGgo...

Quick answer

Use btoa() only for simple ASCII text.

For Unicode-safe Base64 encoding in JavaScript, convert text to UTF-8 bytes first using TextEncoder, then encode those bytes with btoa().

For files and images, use FileReader.readAsDataURL().

For URLs, convert standard Base64 into Base64URL by replacing + with -, / with _, and optionally removing = padding.

Final thoughts

Base64 encoding is simple in theory, but real-world usage gets more complex when you deal with Unicode, files, images, URLs, and APIs.

For quick testing, debugging, and conversion, a browser-based tool like EncodingBase64 can save time because you can encode text, files, images, URL-safe Base64, hex, and URLs without setting up code.

The key rule to remember:

Base64 is an encoding format, not a security feature.

Use it when you need text-safe data representation, not when you need encryption.

How to Decode Base64 Safely: Text, Images, Files, and Common Errors

MOUSTAID Hamza — Fri, 24 Apr 2026 11:17:33 +0000

Base64 decoding looks simple.

You take a string like this:

SGVsbG8gV29ybGQ=

Decode it, and get:

Hello World

But in real projects, Base64 decoding can fail for many reasons:

missing padding
invalid characters
Unicode problems
Base64URL format
binary data being treated as text
image data missing a MIME type
whitespace copied into the string

This guide explains how to decode Base64 safely in JavaScript, Python, and the command line, and how to troubleshoot the most common Base64 decoding issues.

You can also test strings quickly with DecodingBase64, a free client-side Base64 decoder that converts Base64 to text, images, hex output, or downloadable files.

What does Base64 decoding do?

Base64 decoding reverses Base64 encoding.

Base64 represents bytes using readable characters. Decoding converts those characters back into the original bytes.

Those bytes may represent:

plain text
JSON
an image
a PDF
a ZIP file
binary data
an API token
a data URI

This is important:

Base64 decoding does not always produce readable text.

Sometimes the decoded output is binary data.

That is why a good decoder should support text, image, file, and hex output.

Basic Base64 decoding in JavaScript

JavaScript provides atob().

const base64 = "SGVsbG8gV29ybGQ=";
const decoded = atob(base64);

console.log(decoded);
// Hello World

This works for simple ASCII text.

But it can break or produce incorrect output with Unicode text.

Unicode-safe Base64 decoding in JavaScript

If the original text contained Unicode characters, you should decode bytes using TextDecoder.

function decodeBase64Unicode(base64) {
  const binary = atob(base64);

  const bytes = Uint8Array.from(binary, (char) => {
    return char.charCodeAt(0);
  });

  return new TextDecoder("utf-8").decode(bytes);
}

console.log(decodeBase64Unicode("Q2Fmw6kg8J+agA=="));
// Café 🚀

This approach is safer for real-world text because it handles UTF-8 correctly.

Decode Base64 in Python

Python has a built-in base64 module.

import base64

encoded = "SGVsbG8gV29ybGQ="
decoded_bytes = base64.b64decode(encoded)
decoded_text = decoded_bytes.decode("utf-8")

print(decoded_text)
# Hello World

For Unicode text:

import base64

encoded = "Q2Fmw6kg8J+agA=="
decoded = base64.b64decode(encoded).decode("utf-8")

print(decoded)
# Café 🚀

If the output is binary, do not decode it as text. Save it as bytes instead.

Decode Base64 from the command line

On macOS and Linux:

echo "SGVsbG8gV29ybGQ=" | base64 --decode

Output:

Hello World

To decode a Base64 file into a binary file:

base64 --decode input.txt > output.bin

For an image:

base64 --decode image-base64.txt > image.png

The correct output extension depends on the original file type.

How to decode a Base64 image

A Base64 image often looks like this:

data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAA...

This is called a data URI.

It has two important parts:

data:image/png;base64,

and then the Base64 data:

iVBORw0KGgoAAAANSUhEUgAA...

The MIME type tells the browser what kind of file it is:

image/png
image/jpeg
image/webp
image/gif
image/svg+xml

If you only have the raw Base64 string, you may need to know the original MIME type to display or save it correctly.

For image debugging, DecodingBase64’s Base64 to Image tool can turn a Base64 image string back into a preview and downloadable image file.

Base64URL decoding

Some strings are not standard Base64. They are Base64URL.

Base64URL is common in:

JWTs
URL tokens
authentication systems
web-safe identifiers

Standard Base64 uses:

+
/
=

Base64URL may use:

-
_

and often removes padding.

To decode Base64URL in JavaScript, normalize it first:

function base64UrlToBase64(base64Url) {
  let base64 = base64Url
    .replace(/-/g, "+")
    .replace(/_/g, "/");

  while (base64.length % 4 !== 0) {
    base64 += "=";
  }

  return base64;
}

function decodeBase64Url(base64Url) {
  const base64 = base64UrlToBase64(base64Url);
  return atob(base64);
}

console.log(decodeBase64Url("SGVsbG8gV29ybGQ"));
// Hello World

If a standard decoder fails, check whether your string is actually Base64URL.

Common Base64 decoding errors

1. Incorrect padding

Base64 strings often end with:

or:

==

Padding helps make the length valid.

If padding is missing, some decoders fail.

Fix:

function addBase64Padding(base64) {
  while (base64.length % 4 !== 0) {
    base64 += "=";
  }

  return base64;
}

2. Invalid characters

Standard Base64 should usually contain:

A-Z
a-z
0-9
+
/
=

If you see - and _, it may be Base64URL.

If you see spaces, quotes, commas, or copied line breaks, clean the input first.

3. Whitespace problems

Copied Base64 strings may contain line breaks or spaces.

const cleaned = input.replace(/\s/g, "");

4. Decoding binary as text

Not all decoded Base64 is readable.

If the decoded bytes represent an image or file, showing them as text will look broken.

Use a file output, image preview, or hex view instead.

5. Wrong character set

If the decoded text looks strange, it may be a charset issue.

Try UTF-8 first. If that fails, the original data may use another encoding.

Quick answer

To decode Base64 safely:

Clean whitespace.
Detect whether it is standard Base64 or Base64URL.
Add missing padding if needed.
Decode to bytes.
Interpret the bytes correctly as text, image, file, or binary data.

Do not assume every Base64 string is plain text.

Is Base64 secure?

No.

Base64 is not encryption.

Anyone can decode it.

For example:

YXBpX2tleV8xMjM=

decodes to:

api_key_123

So never use Base64 alone to protect sensitive information.

Base64 is useful for representation and transport, not security.

Final thoughts

Base64 decoding is easy when the input is clean ASCII text.

But real-world Base64 often includes images, files, Unicode, Base64URL, missing padding, or binary data.

The safest approach is to decode carefully and inspect the output type.

For fast testing, debugging, and file/image recovery, DecodingBase64 can help because it runs client-side and supports text, image, hex, and file outputs.

Remember:

Base64 decoding gives you bytes. What those bytes mean depends on the original data.

Base64 vs Base64URL vs URL Encoding: When Should You Use Each?

MOUSTAID Hamza — Fri, 24 Apr 2026 11:17:18 +0000

Base64, Base64URL, and URL encoding are often confused because they all seem to “encode” data.

But they solve different problems.

Using the wrong one can break URLs, APIs, JWTs, image data, or browser behavior.

In this guide, we’ll compare:

Base64
Base64URL
URL encoding / percent encoding

You’ll learn what each one does, where each one is useful, and how to choose the right format.

For quick testing, you can use EncodingBase64 for Base64, Base64URL, URL encoding, hex, and image-to-Base64 conversions. If you need to reverse Base64 back into text, images, or files, DecodingBase64 is the matching decoder.

Quick answer

Use Base64 when you need to represent binary data as text.

Use Base64URL when Base64 data must safely appear inside URLs, JWTs, or URL tokens.

Use URL encoding when you need to safely place normal text inside a URL query string or path.

They are not interchangeable.

What is Base64?

Base64 converts bytes into readable ASCII characters.

Example:

Hello World

becomes:

SGVsbG8gV29ybGQ=

Base64 is commonly used for:

sending binary data in JSON
embedding small images
email attachments
API payloads
data URIs
basic text-safe representation

Base64 uses characters like:

A-Z
a-z
0-9
+
/
=

The = character is padding.

When to use Base64

Use Base64 when the original data is binary or byte-based but needs to be represented as text.

Good use cases include:

1. Embedding small images

<img src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAA..." />

2. Sending binary data in JSON

{
  "filename": "avatar.png",
  "content": "iVBORw0KGgoAAAANSUhEUgAA..."
}

3. Encoding small files for transport

Some APIs accept file content as Base64 strings.

4. Encoding credentials in specific protocols

Basic authentication uses Base64 representation for:

username:password

But remember: this is not secure by itself. It must be used over HTTPS.

When not to use Base64

Do not use Base64 for:

encryption
password protection
hiding secrets
large images when normal files work better
URL parameters without URL-safe conversion

Base64 increases data size, often by about one-third.

That is acceptable in many cases, but not always ideal.

What is Base64URL?

Base64URL is a URL-safe version of Base64.

Standard Base64 may contain:

+
/
=

These characters can cause issues in URLs.

Base64URL replaces:

+ with -
/ with _

Padding = is often removed.

Example standard Base64:

SGVsbG8+V29ybGQ/

Base64URL version:

SGVsbG8-V29ybGQ_

Base64URL is common in:

JWTs
URL-safe tokens
password reset links
email verification links
OAuth flows
compact identifiers

Why standard Base64 can break in URLs

Imagine this Base64 string:

abc+def/ghi==

If placed directly inside a URL:

https://example.com/?token=abc+def/ghi==

The + may be interpreted as a space in some URL contexts.

The / may be interpreted as a path separator.

The = can interfere with query parsing.

That is why Base64URL exists.

A safer token would look like:

abc-def_ghi

Base64URL helper in JavaScript

Convert standard Base64 to Base64URL:

function toBase64Url(base64) {
  return base64
    .replace(/\+/g, "-")
    .replace(/\//g, "_")
    .replace(/=+$/g, "");
}

Convert Base64URL back to standard Base64:

function fromBase64Url(base64Url) {
  let base64 = base64Url
    .replace(/-/g, "+")
    .replace(/_/g, "/");

  while (base64.length % 4 !== 0) {
    base64 += "=";
  }

  return base64;
}

Example:

const base64 = "SGVsbG8gV29ybGQ=";
const base64Url = toBase64Url(base64);

console.log(base64Url);
// SGVsbG8gV29ybGQ

What is URL encoding?

URL encoding, also called percent encoding, is different from Base64.

It makes text safe for URLs by replacing unsafe characters with % followed by hexadecimal values.

Example:

hello world

becomes:

hello%20world

Another example:

email@example.com

becomes:

email%40example.com

In JavaScript, you can use:

encodeURIComponent("hello world");
// hello%20world

For a full URL, you may use:

encodeURI("https://example.com/search?q=hello world");
// https://example.com/search?q=hello%20world

encodeURI vs encodeURIComponent

These two are often confused.

encodeURI()

Use it for a full URL:

encodeURI("https://example.com/search?q=hello world");

It keeps URL structure characters like:

:
/
?
&
=

encodeURIComponent()

Use it for a URL parameter value:

const query = encodeURIComponent("hello world & coffee");
const url = `https://example.com/search?q=${query}`;

console.log(url);
// https://example.com/search?q=hello%20world%20%26%20coffee

Most of the time, if you are encoding a query parameter value, use encodeURIComponent().

Base64 vs URL encoding

Here is the key difference:

Feature	Base64	URL Encoding
Main purpose	Represent bytes as text	Make URL text safe
Used for binary data	Yes	No
Used for query params	Not directly	Yes
Output style	`SGVsbG8=`	`hello%20world`
Reversible	Yes	Yes
Security feature	No	No

If you want to encode an image, use Base64.

If you want to safely put a search query inside a URL, use URL encoding.

Base64URL vs URL encoding

Base64URL is still Base64.

It is designed to make Base64 output safe for URLs.

URL encoding is designed to make normal text safe for URLs.

Example:

Original text:

Hello World

Base64:

SGVsbG8gV29ybGQ=

Base64URL:

SGVsbG8gV29ybGQ

URL encoded:

Hello%20World

They look different because they solve different problems.

Real-world examples

Example 1: API file upload

You have image bytes and need to send them in JSON.

Use Base64.

{
  "image": "iVBORw0KGgoAAAANSUhEUgAA..."
}

Example 2: JWT token

JWTs use Base64URL.

A JWT looks like:

header.payload.signature

Each part is Base64URL encoded.

Example 3: Search query

You want a URL like:

https://example.com/search?q=coffee & tea

Use URL encoding:

https://example.com/search?q=coffee%20%26%20tea

Example 4: Small inline SVG or PNG

Use Base64 or URL-encoded SVG depending on the case.

For small PNG/JPEG/WebP assets, Base64 is common.

For SVG, URL encoding can sometimes be more readable and efficient.

Common mistakes

Mistake 1: Using Base64 as encryption

Base64 can be decoded by anyone.

It does not protect data.

Mistake 2: Putting standard Base64 directly in URLs

Characters like +, /, and = can cause issues.

Use Base64URL or URL encode the value.

Mistake 3: Using URL encoding for binary files

URL encoding is not designed for raw binary file representation.

Use Base64 instead.

Mistake 4: Forgetting to decode in the right order

If data is URL encoded and Base64 encoded, the order matters.

For example:

URL decode
Base64 decode

or the reverse, depending on how the data was originally encoded.

Mistake 5: Not handling Unicode

JavaScript’s btoa() and atob() are not always Unicode-safe by themselves.

Use TextEncoder and TextDecoder when working with modern text.

Which one should you choose?

Use this simple rule:

Situation	Use
Encode text or binary as ASCII	Base64
Put Base64 safely in a URL	Base64URL
Encode a URL query parameter	URL encoding
Encode an image as text	Base64
Encode a JWT payload	Base64URL
Encode spaces and symbols in URLs	URL encoding
Hide sensitive data	None of these

For sensitive data, use proper encryption, hashing, HTTPS, and secure storage depending on the use case.

Final thoughts

Base64, Base64URL, and URL encoding are all useful, but they are not the same.

Base64 helps represent bytes as text.

Base64URL makes Base64 safer for URLs and tokens.

URL encoding makes normal URL text safe.

When debugging encoded data, first identify what kind of encoding you are dealing with. Then choose the right tool or function.

For browser-based testing, EncodingBase64 is useful for encoding workflows like Base64, Base64URL, URL encoding, image to Base64, and hex. For reverse workflows, DecodingBase64 helps decode Base64 back into text, images, hex, or files.

The main thing to remember:

Encoding is about representation. It is not the same as encryption.

A QA engineer's first AI testing project - FastAPI + local LLM + pytest

Sara Bezjak — Fri, 24 Apr 2026 11:15:15 +0000

I'm an automation engineer that writes mostly UI tests with some API sprinkled in. A recruiter wrote to me about an interesting job - AI/LLM testing. I was curious to learn more so I asked the model itself: what skills do I need to learn? The answer was this project.

What is it

A FastAPI service with one endpoint (/ask) that forwards a question to a local LLM (Ollama running llama3.2) and returns the answer. Plus a pytest suite.

~90 lines of app code, 23 tests, 100% coverage, two-tier test split (fast <1s, full ~90s).

The point was to learn what AI testing actually looks like compared to UI/API testing.

Repo: https://github.com/sbezjak/llm-api-testing

One honest thing up front. The suite worked first try. That made it harder to learn from, not easier — when nothing breaks, you don't have to understand it. I spent more time reading the code than I would have spent writing it.

Process timeline

1. Read every line before running anything. Docs, code, tests, setup. I wanted the big picture — classes, endpoints, test structure in my head before I touched anything.

2. Ask questions instead of copy-pasting. It's easy to create something that passes. It's harder to understand why it does. I spent 2 hours just discussing the project with the model. Questions like: Why 70% and not 100%? What does ASGITransport actually do? Why does ConnectError map to 503 and HTTP errors to 502? Why mock at all with respx? What's xfail and why is it used like this? What's temperature?

3. Ran it. All passed. But "10 passed in 99s" wasn't enough. I wanted to see which tests hit the model, how long each took, what the model actually answered. So I added structured logging:

POST /ask verdict=allowed status=200 elapsed=0.42s answer='Paris.'

And a pytest-html report with per-test captured logs. Now every test run is a document I can read.

4. Iterate with the model. Added logs, reports, comments. Asked about code I didn't understand — why something was there, what a piece did. This is where the differences between UI and AI testing started to click. Probabilistic vs deterministic. The 70% Paris case.

5. Make it production-ish. Asked how a real team would harden this. Mocking Ollama and 100% coverage were added in this step.

The thing that actually clicked — probabilistic vs deterministic

The consistency test sends "What is the capital of France?" ten times and asserts ≥70% of answers contain "paris".

answers = [await ask(prompt) for _ in range(10)]
hits = sum(1 for a in answers if "paris" in a.lower())
assert hits / len(answers) >= 0.7

In UI testing, same input produces the same output. You assert on exact values. assert button.opens_modal() == True.

LLMs don't work like that. Same prompt, different valid answers every call — "Paris.", "The capital is Paris.", a paragraph about French geography. The model samples from a distribution. There is no single right string.

So you assert on properties of the distribution, or on the envelope of acceptable answers. assert ≥70% of answers contain "paris". 70% is arbitrary — high enough to catch regressions, low enough to tolerate the model's variance. In a real system you'd tune per prompt.

Point vs region. Four years of UI-testing instincts took a while to shift.

The three bugs and what they taught me

Bug 1 — latency test failing at 35s.

First thought: my M1 is slow. Then I ran ollama run llama3.2 "say hi" directly in the terminal — instant. So the model was fine.

llama3.2 is chatty. Asking "string" produced an essay on null-termination and Unicode. The 35 seconds was generation time, not system latency.

Fix: "options": {"num_predict": 200} to cap output tokens. Warm requests dropped to 1-3 seconds.

Lesson: traditional APIs return what you ask for. LLMs return what they feel like returning. Latency tests measure output length unless you constrain it.

Bug 2 — coverage stuck at 85%.

Cause: no test exercised Ollama failure paths.

Fix: three mocked tests with respx — unreachable → 503, Ollama 5xx → 502, empty response → 502. Coverage hit 100%. New tests run in <50ms each because no real model is involved.

Lesson: check coverage reports. Gaps usually point at untested failure modes, not untested happy paths.

Bug 3 — moderation filter false positives.

The moderation filter is a substring blocklist — a Python list of phrases like "how to kill", "how to hack", etc. Any question containing one gets refused with a 400. Simple: "how to kill a process on linux" contains "how to kill", so a normal dev question gets blocked.

Fix: added the false positive to the benign dataset with pytest.mark.xfail and a written reason. The test now runs, fails as expected, and shows as a yellow dot in the report instead of red. Documented in the suite itself.

It flips to green the day the substring is replaced with a real classifier — a model that understands intent ("is this user actually trying to cause harm?") instead of just matching strings. That could be a small fine-tuned model, an open-source moderation model like Llama Guard, or a commercial moderation API. The upgrade closes the false-positive gap, the test starts passing, and xfail(strict=False) signals "unexpectedly passed" — the cue to remove the marker.

Lesson: xfail makes the suite record what's broken, not just what works. I'd only used xfail for flaky tests before, not as living documentation of known bugs. Much better than hiding a bug in a backlog ticket.

What I still don't fully understand

The ASGI internals ASGITransport relies on. I know what it does, not what's happening inside.
When respx is the right call vs building a proper fake.
Embedding similarity math beyond "cosine measures angle."
What a real production eval harness looks like.

From a QA perspective

Most UI-testing instincts didn't transfer. Equality assertions, fixed latency thresholds, asserting a single correct outcome — all had to shift.

What did transfer: discipline around edge cases, thoughts about what happens when the upstream service dies, care about keeping the feedback loop fast, coverage reports.

Setting up a local model was new. Using it as a dependency in a test suite was new. Testing something that returns different valid outputs every call was new. If you're a QA engineer looking at this direction — the probability side is the new thing. The rest is still testing.

How to run it

# Install & start Ollama
brew install ollama
ollama serve             # leave running in its own terminal
ollama pull llama3.2     # in another terminal

# Python env
python3 -m venv .venv && source .venv/bin/activate
pip install -r requirements.txt

# Run the API
uvicorn app.main:app --reload --port 8000
# → http://localhost:8000/docs

# Tests
pytest -m "not ollama"   # fast tier, no Ollama needed, ~1s
pytest                   # full suite with HTML reports

Conclusion

When you're testing robustness (did the system stay well-behaved?) instead of correctness (did the right thing happen?), you assert the shape of acceptable failure, not the shape of success. AI systems fail in more ways, so the distinction matters more — a 500 is always a bug; anything else might be correct behavior for an edge case.

Repo: https://github.com/sbezjak/llm-api-testing

Next up — 5 more projects on the list: eval harness, RAG with observability, red-team suite, agent testing, model benchmarking. Writing each one up as I go.

Step-by-Step Webhook Signature Verification for Any Sender

137Foundry — Fri, 24 Apr 2026 11:15:03 +0000

Webhook signature verification is the first line of defense against forged events. Without it, any HTTP client that knows your endpoint URL can POST fabricated events. The verification process is the same across most webhook senders, even when the specific header names and hash algorithms differ.

This guide walks through implementing signature verification for a webhook receiver, from parsing the header to computing the HMAC to returning the right response.

Step 1: Get the Raw Request Body Before Any Parsing

This is the step most implementations get wrong. Signature verification computes an HMAC over the raw request body bytes. The HMAC must be computed before any framework deserialization happens.

Web frameworks parse JSON bodies automatically. When they do, they may normalize whitespace, change encoding, or reorder keys. Computing the HMAC over the parsed-then-re-serialized body will produce a different hash than the sender computed over the original bytes. The verification will fail even for valid payloads.

In Python with FastAPI:

from fastapi import Request

@app.post("/webhooks/events")
async def receive_webhook(request: Request):
    raw_body = await request.body()  # raw bytes, before any JSON parsing
    signature = request.headers.get("X-Signature-256", "")
    # verify against raw_body, not json.loads(raw_body)

In Node.js with Express:

app.post('/webhooks/events', express.raw({ type: 'application/json' }), (req, res) => {
  const rawBody = req.body;  // Buffer, not parsed JSON
  const signature = req.headers['x-signature-256'];
  // verify against rawBody
});

The express.raw() middleware captures the body as a Buffer instead of parsing it. Without it, req.body contains the parsed JSON object, which breaks verification.

Step 2: Parse the Signature Header

Webhook senders typically include both the HMAC hash and a timestamp in the signature header, either as separate headers or combined in a single header. Stripe combines them in a single header with a specific format:

Stripe-Signature: t=1714000000,v1=abc123...

Parse the header to extract the timestamp and the hash:

def parse_stripe_signature(header: str) -> dict:
    parts = {}
    for part in header.split(","):
        key, value = part.split("=", 1)
        parts[key] = value
    return parts

sig_parts = parse_stripe_signature(request.headers.get("Stripe-Signature", ""))
timestamp = sig_parts.get("t", "")
received_hash = sig_parts.get("v1", "")

Other senders use a simpler format with the hash prefixed:

X-Signature-256: sha256=abc123...

received_hash = signature_header.removeprefix("sha256=")

Check the sender's documentation for their specific header format. The concept is the same; only the parsing differs.

Step 3: Compute the Expected HMAC

With the raw body bytes and the shared secret, compute the expected HMAC using the algorithm your sender specifies. Most use SHA-256.

For Stripe-style signatures where the hash is computed over {timestamp}.{body}:

import hmac
import hashlib

def compute_hmac(raw_body: bytes, timestamp: str, secret: str) -> str:
    signed_payload = f"{timestamp}.".encode() + raw_body
    return hmac.new(
        secret.encode(),
        signed_payload,
        hashlib.sha256
    ).hexdigest()

For simpler senders where the hash is computed directly over the body:

def compute_hmac_simple(raw_body: bytes, secret: str) -> str:
    return hmac.new(
        secret.encode(),
        raw_body,
        hashlib.sha256
    ).hexdigest()

Step 4: Compare Using Constant-Time Equality

Never use == to compare the expected and received hashes. Standard string equality short-circuits on the first differing character, which creates a timing side channel. An attacker can measure how long the comparison takes to determine how many leading characters of the hash they got right, eventually reconstructing a valid hash without knowing the secret.

is_valid = hmac.compare_digest(expected_hash, received_hash)

hmac.compare_digest takes the same amount of time regardless of where the strings differ. The equivalent in JavaScript uses the crypto module's timingSafeEqual function.

Step 5: Check the Timestamp Window

If the sender includes a timestamp in the signature header, check that it's within an acceptable window (typically five minutes). This prevents replay attacks where an attacker captures a valid signed request and re-sends it later.

import time

def is_timestamp_valid(timestamp: str, max_age_seconds: int = 300) -> bool:
    try:
        event_time = int(timestamp)
        return abs(time.time() - event_time) < max_age_seconds
    except (ValueError, TypeError):
        return False

If the timestamp is more than five minutes old, return 400 and log the event for investigation. The sender should not be sending payloads with stale timestamps; this is a potential replay attempt.

Step 6: Return the Right Status Codes

The response status code tells the sender whether to retry:

200: Event received and accepted. Don't retry.
400: Invalid signature or malformed request. Don't retry (retries won't fix a tampered payload).
500: Server error. Retry according to retry policy.

Return 400 on signature failures, not 500. A 500 tells the sender to retry, which is wrong behavior for a forged payload. A 400 tells the sender the request was rejected as invalid.

Testing the Verification Logic

The most important tests to write:

Valid signature passes verification
Tampered body fails verification
Wrong secret fails verification
Missing signature header returns 400
Expired timestamp is rejected

Use Postman to send test requests with custom signature headers to a running server. ngrok lets you test against a real external sender during development.

Handling Senders That Deviate from the Standard Pattern

Not all webhook senders follow the same verification scheme. Most use HMAC-SHA256 with a shared secret, but the payload construction, header format, and timestamp handling vary.

Timestamp in the signed payload. Stripe constructs the signed payload as {timestamp}.{raw_body}, not just the raw body. This means you need to extract the timestamp from the signature header, construct the signed string manually before computing the HMAC, and verify that string against the received hash. A receiver that computes the HMAC over just the raw body will fail verification for Stripe webhooks even if the secret is correct.

Multiple hash versions. Some senders include multiple hash versions in the header (for example, both a v0 and v1 hash). The receiver should check whether any of the provided hashes matches the expected value, rather than requiring a specific version. This allows the sender to rotate their signing scheme without breaking receivers.

No timestamp. Some simpler webhook senders include only the HMAC hash with no timestamp. For these, timestamp validation isn't possible, but you should still verify the HMAC. The absence of a timestamp means replay attacks are technically possible, which is worth noting in your integration documentation.

Custom algorithms. A small number of senders use HMAC-SHA1 instead of SHA256. HMAC-SHA1 is not considered broken for this use case, but SHA256 is preferred. Implement the algorithm your specific sender specifies.

Common Verification Failures in Production

A few signature verification failures that appear consistently across production webhook integrations:

Middleware that reads the body. Some logging middleware or request parsing middleware reads the request body before your verification code runs. If the body is consumed and not replaced with the original bytes, your verification code gets an empty body. Make sure any body-reading middleware restores the raw bytes before the request reaches the webhook handler.

Content-Type normalization. Some frameworks normalize or re-parse the body when the Content-Type header is application/json. Using express.raw() or the framework-equivalent prevents this. Always test signature verification explicitly in your actual framework environment, not just in isolation.

Header name case sensitivity. HTTP header names are case-insensitive by spec but some implementations are not. If your verification code looks for X-Signature-256 but the sender sends x-signature-256, some frameworks will pass it through and some won't. Use case-insensitive header lookup.

For the broader receiver architecture (async processing, idempotency, failure handling), How to Build a Webhook Receiver That Handles Real-World Traffic covers how signature verification fits into the complete pattern.

This development service builds and maintains data integration infrastructure including webhook receivers, event processors, and API integrations for production workloads.

Photo by Hans on Pixabay