Forem: Muhammad Hamid Raza

The Vercel Security Breach of April 2026: What Happened and What You Should Do Right Now

Muhammad Hamid Raza — Tue, 21 Apr 2026 18:12:22 +0000

Every developer's worst nightmare? Waking up to find out the platform you trust with your production secrets just had a security incident. 😬

That's exactly what happened in April 2026 — Vercel, one of the most widely-used deployment platforms in the frontend world, confirmed a real security breach. Not a rumor. Not a hypothetical. An actual attack by a sophisticated threat actor who got further than anyone would have liked.

So what actually happened? Who was affected? And what should you do with your environment variables right now? Let's break it all down clearly — no panic, just facts and action steps.

What Is the Vercel April 2026 Security Incident?

On April 19, 2026, Vercel's security team published a bulletin confirming that unauthorized parties had gained access to certain internal Vercel systems.

The attack did not start with Vercel directly. It started with a third-party AI tool called Context.ai, which was being used by a Vercel employee. The attacker compromised Context.ai's Google Workspace OAuth app, which then gave them access to that employee's Vercel Google Workspace account.

From there, the attacker was able to access some Vercel environments and non-sensitive environment variables — things like API keys, tokens, database credentials, and signing keys that were stored in plaintext.

The short version: a third-party tool got compromised, and that became the entry point into Vercel's systems. Classic supply chain attack.

Why This Incident Matters

You might be thinking, "I'm just a solo dev or a small team — this probably doesn't affect me." That's a fair first instinct, but let's think about it for a second.

If you have ever stored an API key, a database URL, or a signing secret in Vercel as a non-sensitive environment variable, there is now a reason to audit that. The attacker was described by Vercel as "highly sophisticated" based on their speed and detailed knowledge of Vercel's internal systems.

This matters because:

Your production secrets may be more exposed than you think. The attack targeted variables that decrypt to plaintext — exactly the kind most developers store without thinking twice.
Supply chain attacks are becoming the new normal. The breach didn't start at Vercel. It started at a small third-party AI tool. That's the lesson here.
You can't rely on "deleting your project" as a fix. Vercel explicitly warned: deleting your project or account does NOT eliminate risk if the secrets were already exposed.

This incident is a real-world reminder that security is everyone's job — not just the platform's.

Key Facts: What We Know So Far

Here is what Vercel has confirmed as of April 21, 2026:

✅ Origin of the attack: Compromise of Context.ai's Google Workspace OAuth app
✅ What was accessed: Non-sensitive environment variables (those stored in plaintext)
✅ What was NOT compromised: Environment variables marked as "sensitive" (stored in a way that prevents them from being read)
✅ npm packages: Confirmed safe — no Vercel npm packages were tampered with
✅ Ongoing investigation: Vercel is working with Mandiant, GitHub, Microsoft, npm, Socket, and law enforcement

The attacker gained access via a Google Workspace OAuth app with this identifier:

110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com

If you are a Google Workspace admin, check your connected OAuth apps immediately.

Benefits of Acting Fast: What Rotation Buys You

Look, no one enjoys rotating credentials. It's tedious. But here's why you should treat it like an emergency:

Stops active exploitation. If a secret was accessed, rotating it immediately cuts off the attacker's access — even if they already have the old value.
Reduces blast radius. The fewer exposed secrets that remain active, the smaller the damage window.
Forces a good habit. Most developers set secrets once and forget them. This incident is a forced spring cleaning.
Protects your users and customers. If your API key connects to a payment processor, a database, or a third-party service — a leaked key puts real users at risk, not just your infrastructure.

Rotating credentials after a breach is not optional. It's damage control with a timer on it.

Sensitive vs Non-Sensitive Environment Variables

This distinction is probably the biggest lesson from this incident.

Feature	Non-Sensitive Variable	Sensitive Variable
Stored as	Plaintext (decryptable)	Encrypted, unreadable after save
Risk if accessed	High — value is exposed	Low — value cannot be read
Recommended for	Non-secret config values	API keys, tokens, passwords
Was it affected?	✅ Yes, potentially	❌ No evidence of access

Before this incident, many developers used non-sensitive variables for secrets simply because it was easier — you could go back and read the value if you forgot it. That convenience comes with a cost. Always mark real secrets as sensitive in Vercel. You can't read them back afterward, but that's the point.

Best Tips and Immediate Action Steps 🔧

Here is what Vercel recommends, and what you should do right now:

Do's:

✅ Rotate all non-sensitive environment variables immediately. API keys, database URLs, tokens, signing keys — all of it. Treat them as compromised.
✅ Enable Multi-Factor Authentication (MFA) on your Vercel account. Use an authenticator app or set up a passkey.
✅ Switch to sensitive environment variables for all secrets going forward. Vercel has now updated the default — new variables will be marked sensitive by default.
✅ Review your activity log in the Vercel dashboard for anything suspicious.
✅ Check recent deployments for anything unexpected. Delete if in doubt.
✅ If you are a Google Workspace admin, check for the OAuth app ID listed above and revoke it if present.

Don'ts:

❌ Don't just delete your project and call it done. Exposed secrets still work after deletion.
❌ Don't assume "I'm a small project so I wasn't targeted." Automated attackers don't discriminate by project size.
❌ Don't leave old credentials active while you "get around to" rotating them. The window matters.

Common Mistakes Developers Make With Environment Variables

This breach shines a light on habits that are surprisingly common in the developer community.

1. Storing secrets as non-sensitive variables "for convenience"
The number one mistake. Developers want to be able to read a key back if they forget it. But convenience and security are often in conflict — and this incident is a perfect example of that trade-off going wrong.

2. Not having MFA on deployment accounts
Your Vercel account has access to your production environment. If someone gets into your account without MFA, you have zero friction stopping them. Enable it today.

3. Forgetting to rotate secrets after a team member leaves
Environment variables often outlive the person who set them. This is a good moment to audit who set what and when.

4. Assuming the platform handles everything
Vercel is a great platform. But security is a shared responsibility. The platform can only protect what you've told it to protect. Mark things as sensitive. Enable MFA. Review logs.

5. Not monitoring third-party OAuth app access
The attack originated from a third-party AI tool with Google Workspace OAuth access. Most developers and admins never review connected apps. Now is a great time to audit what has access to your workspace.

Conclusion

The Vercel April 2026 security incident is a useful and important reminder: no platform is immune, and supply chain attacks are a real and growing threat.

The breach didn't come through a Vercel vulnerability. It came through a third-party AI tool, through a Google Workspace OAuth connection, through one employee's account — and that chain was enough to reach production environment variables.

The good news? Vercel responded quickly, transparently, and in collaboration with industry partners. npm packages are safe. Sensitive variables were not accessed. The team is actively shipping security improvements.

Your job right now is simple: rotate your secrets, enable MFA, and mark everything sensitive going forward. That's it. Three things. Do them today.

If this article helped you understand what happened and what to do next, consider sharing it with your team or developer friends — it might save someone a stressful morning.

For more practical developer content like this, head over to hamidrazadev.com — I write about real-world dev topics, tools, and security updates regularly. 🚀

How to Make Your Next.js App Highly SEO Optimized: Metadata, LD+JSON, Google Search Console, Bing & More

Muhammad Hamid Raza — Sun, 19 Apr 2026 16:50:08 +0000

So you built a beautiful Next.js app. The UI is clean, the code is smooth, and you're genuinely proud of it. There's just one problem — Google has no idea it exists. 😅

SEO is one of those things developers push to the end of the to-do list. And that's exactly where a lot of great projects quietly die. No traffic. No visibility. No love.

The good news? Next.js is one of the most SEO-friendly frameworks out there. But "SEO-friendly" only means something if you set things up right. You need proper metadata, structured data (LD+JSON), a sitemap, a robots file — and then you need to actually tell Google and Bing your site exists.

That last part is something most tutorials completely skip. Your site doesn't magically appear in search results the moment you deploy. You have to register it, verify ownership, and submit your sitemap. Let's cover everything from start to finish. 🚀

What Does "SEO Optimized" Actually Mean?

SEO stands for Search Engine Optimization. At its core, it means making your website easy for search engines like Google to read, understand, and rank.

Think of Google as a massive library and Googlebot as the librarian. The librarian crawls every webpage it finds, reads the content, and decides where to file it. SEO is how you help that librarian understand exactly what your page is about and why it deserves a good spot.

For a Next.js app, this covers four areas:

Technical SEO — server rendering, page speed, clean HTML structure
On-page SEO — titles, descriptions, headings, canonical URLs
Structured Data — LD+JSON schemas that give Google extra context
Discovery — telling Google and Bing your site exists via Search Console tools

Next.js handles the technical foundation well. Your job is to build on top of it.

Why This Matters for Your Next.js App

You can have the best product in the world, but if it doesn't appear in search results, it effectively doesn't exist for most users.

Here's the practical reality:

Organic traffic is free. Unlike paid ads, a well-optimized page can bring consistent visitors for months or years at zero cost.
Better rankings mean more trust. Users instinctively trust pages that rank higher.
SEO and good UX go hand in hand. Fast pages, clean structure, and clear content help both users and crawlers.
Career value. Developers who understand SEO are significantly more valuable to any team building a public-facing product.

Whether you're building a portfolio, blog, SaaS, or tool — SEO matters from day one.

Part 1: Setting Up Metadata in Next.js (App Router)

The App Router (Next.js 13+) introduced a clean Metadata API that replaces manually managing <head> tags. This is the foundation of all on-page SEO.

Static Metadata

Export a metadata object from any page.tsx or layout.tsx:

// app/layout.tsx
import type { Metadata } from "next";

export const metadata: Metadata = {
  metadataBase: new URL("https://hamidrazadev.com"),
  title: "Hamid Raza — Frontend Developer & Blogger",
  description: "Tutorials, tips, and tools for modern web development.",
  keywords: ["Next.js", "React", "Frontend Development", "Web Dev Blog"],
  authors: [{ name: "Hamid Raza", url: "https://hamidrazadev.com" }],
  creator: "Hamid Raza",
  openGraph: {
    title: "Hamid Raza — Frontend Developer & Blogger",
    description: "Tutorials, tips, and tools for modern web development.",
    url: "https://hamidrazadev.com",
    siteName: "Hamid Raza Dev",
    images: [
      {
        url: "/og-image.png",
        width: 1200,
        height: 630,
        alt: "Hamid Raza Developer Blog",
      },
    ],
    locale: "en_US",
    type: "website",
  },
  twitter: {
    card: "summary_large_image",
    title: "Hamid Raza — Frontend Developer & Blogger",
    description: "Tutorials, tips, and tools for modern web development.",
    images: ["/og-image.png"],
    creator: "@hamidrazadev",
  },
  robots: {
    index: true,
    follow: true,
  },
  alternates: {
    canonical: "https://hamidrazadev.com",
  },
};

💡 Important: Always set metadataBase. Without it, Next.js can't resolve relative image URLs for Open Graph, and your social previews will break silently.

Dynamic Metadata for Blog Posts

For pages like /blog/[slug], use generateMetadata():

// app/blog/[slug]/page.tsx
import type { Metadata } from "next";

type Props = { params: { slug: string } };

export async function generateMetadata({ params }: Props): Promise<Metadata> {
  const post = await getPostBySlug(params.slug);

  return {
    title: `${post.title} — Hamid Raza Dev Blog`,
    description: post.excerpt,
    alternates: {
      canonical: `https://hamidrazadev.com/blog/${params.slug}`,
    },
    openGraph: {
      title: post.title,
      description: post.excerpt,
      url: `https://hamidrazadev.com/blog/${params.slug}`,
      type: "article",
      publishedTime: post.publishedAt,
      authors: ["Hamid Raza"],
      images: [{ url: post.thumbnail, width: 1200, height: 630, alt: post.title }],
    },
  };
}

Every post now gets unique, accurate metadata — automatically. ✅

Adding the Google Verification Tag via Metadata

When you verify your site with Google Search Console (covered later), one method is adding a verification meta tag. In Next.js App Router, you can do this directly in your root layout.tsx:

// app/layout.tsx
export const metadata: Metadata = {
  // ...your other metadata
  verification: {
    google: "YOUR_VERIFICATION_CODE_FROM_GOOGLE",
  },
};

This generates the <meta name="google-site-verification" content="..."> tag in your <head> automatically. No manual HTML editing required.

Note: There's a known quirk in some Next.js versions where the google property inside verification doesn't render as expected. If you run into that, use the other field instead:

verification: {
  other: {
    "google-site-verification": "YOUR_VERIFICATION_CODE",
  },
},

Both produce the exact same meta tag in your HTML.

Part 2: Adding LD+JSON Structured Data

Structured data (LD+JSON) is how you speak Google's language. It gives search engines extra context about your content in a machine-readable format — and it can unlock rich results in search: article previews, FAQ dropdowns, breadcrumbs, and more.

Reusable JsonLd Component

// components/JsonLd.tsx
type JsonLdProps = {
  data: Record<string, unknown>;
};

export default function JsonLd({ data }: JsonLdProps) {
  return (
    <script
      type="application/ld+json"
      dangerouslySetInnerHTML={{ __html: JSON.stringify(data) }}
    />
  );
}

Blog Post Schema (BlogPosting)

// app/blog/[slug]/page.tsx
import JsonLd from "@/components/JsonLd";

export default function BlogPost({ post }) {
  const schema = {
    "@context": "https://schema.org",
    "@type": "BlogPosting",
    headline: post.title,
    description: post.excerpt,
    image: post.thumbnail,
    datePublished: post.publishedAt,
    dateModified: post.updatedAt,
    author: {
      "@type": "Person",
      name: "Hamid Raza",
      url: "https://hamidrazadev.com",
    },
    publisher: {
      "@type": "Organization",
      name: "Hamid Raza Dev",
      logo: {
        "@type": "ImageObject",
        url: "https://hamidrazadev.com/logo.png",
      },
    },
    mainEntityOfPage: {
      "@type": "WebPage",
      "@id": `https://hamidrazadev.com/blog/${post.slug}`,
    },
  };

  return (
    <>
      <JsonLd data={schema} />
      {/* blog content */}
    </>
  );
}

Person Schema (for Portfolio Sites)

{
  "@context": "https://schema.org",
  "@type": "Person",
  "name": "Hamid Raza",
  "url": "https://hamidrazadev.com",
  "jobTitle": "Frontend Developer",
  "sameAs": [
    "https://twitter.com/hamidrazadev",
    "https://github.com/hamidrazadev",
    "https://linkedin.com/in/hamidrazadev"
  ]
}

FAQ Schema (Great for Organic Traffic)

FAQ schemas can appear as expandable dropdowns directly in Google's search results, which dramatically improves click-through rate.

{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "What is Next.js?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Next.js is a React framework for production-grade web applications with built-in SSR and SSG support."
      }
    }
  ]
}

🔧 Always test your structured data using Google's Rich Results Test before publishing. A small syntax error can make Google ignore your entire schema silently.

Part 3: Sitemap and robots.txt

Auto-Generated Sitemap

// app/sitemap.ts
import { MetadataRoute } from "next";

export default async function sitemap(): Promise<MetadataRoute.Sitemap> {
  const posts = await getAllPosts();

  return [
    {
      url: "https://hamidrazadev.com",
      lastModified: new Date(),
      changeFrequency: "monthly",
      priority: 1,
    },
    ...posts.map((post) => ({
      url: `https://hamidrazadev.com/blog/${post.slug}`,
      lastModified: new Date(post.updatedAt),
      changeFrequency: "weekly" as const,
      priority: 0.8,
    })),
  ];
}

This auto-generates your sitemap at /sitemap.xml. Every new post gets included automatically.

robots.txt

// app/robots.ts
import { MetadataRoute } from "next";

export default function robots(): MetadataRoute.Robots {
  return {
    rules: {
      userAgent: "*",
      allow: "/",
      disallow: ["/api/", "/admin/", "/dashboard/"],
    },
    sitemap: "https://hamidrazadev.com/sitemap.xml",
  };
}

Part 4: Adding Your Site to Google Search Console

This is the step most tutorials skip — and it's arguably the most important. Just having a sitemap isn't enough. You need to register your site with Google so it knows to crawl it, and so you can monitor performance, fix issues, and track which pages are indexed.

Step 1: Go to Google Search Console

Head to search.google.com/search-console and sign in with your Google account.

Step 2: Add a Property

Click "Add Property". You'll see two options:

Property Type	What It Covers	Verification Method
Domain	All subdomains, HTTP + HTTPS (e.g., `hamidrazadev.com`)	DNS TXT record only
URL Prefix	One specific URL (e.g., `https://hamidrazadev.com`)	Multiple methods

Recommendation: Use the Domain property type. It covers everything under your domain in one place — www, non-www, HTTP, HTTPS, and all subdomains. This gives you a complete picture in one dashboard.

Step 3: Verify Ownership

Google needs to confirm you actually own the site. There are five verification methods:

Method 1: DNS TXT Record (Recommended for Domain properties)

Google gives you a TXT record that looks like this: google-site-verification=XXXXXXXXXXXXXXX

Log into your domain provider (Namecheap, GoDaddy, Hostinger, Cloudflare, etc.) and add this as a TXT DNS record. Leave the "Name/Host" field blank or set it to @. The propagation usually takes a few minutes, but Google says it can sometimes take up to 24–48 hours.

This is the most reliable method because it doesn't depend on any code in your app. It stays valid even if you rebuild or redeploy your site.

Method 2: HTML Meta Tag (URL Prefix only)

Google gives you a meta tag like:

<meta name="google-site-verification" content="YOUR_CODE" />

In Next.js, add this via the verification field in your root layout.tsx as shown in Part 1. Google checks for this tag on your homepage and verifies your ownership quickly.

Method 3: HTML File Upload

Download a small HTML file from Google and upload it to your Next.js /public folder. The file becomes accessible at https://yourdomain.com/google-site-verification.html. Google fetches it and verifies you.

/public/googleXXXXXXXXXXX.html

Method 4: Google Analytics

If you already have Google Analytics 4 installed on your site (using the same Google account), you can verify via that. Google just checks that the GA tracking code is present on your homepage.

Method 5: Google Tag Manager

Same concept — if GTM is active on your site and your Google account has access, GTM can be used for verification.

💡 You can keep multiple verification methods active at the same time. Many developers use both DNS and the HTML meta tag for redundancy — if one breaks during a deployment, the other keeps verification active.

Step 4: Submit Your Sitemap

Once verified, go to Indexing → Sitemaps in the left menu. Enter your sitemap URL:

https://hamidrazadev.com/sitemap.xml

Click Submit. Google will start reading your sitemap and scheduling pages for crawling. You can check back in a day or two to see how many pages were discovered.

Step 5: Use the URL Inspection Tool

This is one of the most useful tools in Google Search Console. You can paste any URL from your site and see:

Whether it's indexed or not
When Google last crawled it
What the rendered HTML looks like (after JavaScript runs)
Whether your structured data was detected correctly
Any crawl or indexing errors

If a page isn't indexed yet and you want to speed things up, click "Request Indexing" inside the URL Inspection tool. Google adds that URL to its priority crawl queue. This doesn't guarantee immediate indexing, but it usually cuts the wait from days down to hours for healthy pages.

Keep in mind: There's a daily quota on indexing requests. Use it strategically — for new important pages, after major content updates, or after fixing a technical issue.

Part 5: Adding Your Site to Bing Webmaster Tools

Bing is the world's second-largest search engine and powers searches across DuckDuckGo, Yahoo, and even some ChatGPT web queries. Ignoring Bing means ignoring a portion of your potential audience.

The good news: if you've already set up Google Search Console, getting into Bing Webmaster Tools is extremely fast.

Step 1: Go to Bing Webmaster Tools

Go to bing.com/webmasters and sign in. You can use a Microsoft account, a Google account, or a Facebook account.

Step 2: Choose How to Add Your Site

Bing gives you two paths right away:

🚀 Fast Path: Import from Google Search Console

This is by far the easiest and fastest method. Since your site is already verified in GSC, Bing can import it directly — no separate verification needed.

Click "Import from Google Search Console"
Click "Continue" and sign in with the same Google account that has access to your GSC property
Grant Bing permission to access your GSC data
Select the sites you want to import and click "Import"

That's it. Your site is added and automatically verified. Bing also imports your existing sitemaps. It may take up to 48 hours for traffic data to start appearing in the dashboard.

Note: Bing periodically validates your ownership by syncing with your GSC account. If you ever revoke GSC access, you'll need to re-verify using one of the manual methods below.

Manual Path: Add Site Manually

If you'd prefer not to connect your GSC account, you can add the site manually:

Enter your site URL under "Add your site manually" and click "Add"
Choose a verification method

Bing's manual verification methods are:

Method	How It Works
Domain Connect	Bing automatically connects to supported DNS providers (GoDaddy, etc.) and verifies instantly
XML File Upload	Download an XML file from Bing and upload it to your site's root directory
HTML Meta Tag	Add a Bing-specific meta tag to your homepage's `<head>`
DNS TXT / CNAME Record	Add a TXT or CNAME record to your domain's DNS settings

The meta tag method is the most practical for Next.js developers. Bing gives you a tag like this:

<meta name="msvalidate.01" content="YOUR_BING_VERIFICATION_CODE" />

In Next.js, add it to your root layout.tsx:

export const metadata: Metadata = {
  // ...
  verification: {
    other: {
      "msvalidate.01": "YOUR_BING_VERIFICATION_CODE",
    },
  },
};

Deploy, then return to Bing Webmaster Tools and click "Verify".

Step 3: Submit Your Sitemap to Bing

Even if you imported from GSC, it's worth manually confirming your sitemap in Bing.

In the left sidebar, go to Sitemaps
Click "Submit sitemap"
Enter your sitemap URL: https://yourdomain.com/sitemap.xml
Click Submit

Bing will start crawling and indexing your pages from the sitemap.

Step 4: Use the URL Inspection Tool

Just like GSC, Bing Webmaster Tools has a URL Inspection tool. You can check if a specific URL is indexed in Bing, see when it was last crawled, and spot any crawl errors. It also shows whether your page is blocked by robots.txt or has other issues preventing indexing.

Part 6: IndexNow — Tell Bing About New Pages Instantly

This is a bonus level that most developers don't know about. 👀

IndexNow is an open protocol that lets you instantly notify search engines when you publish or update content. Instead of waiting for Bingbot to eventually crawl your site on its own schedule, you proactively send a ping saying "hey, this page just changed."

Currently, IndexNow is supported by Bing, Yandex, DuckDuckGo (via Bing), Naver, Seznam, and Yep. When you submit to one, all participating engines get notified automatically. Google doesn't support IndexNow yet.

Setting It Up in Next.js

Step 1: Generate an API key

Go to Bing's IndexNow page and generate a key. It's a random hex string.

Step 2: Host the key file

Create a .txt file in your /public folder named after your key:

/public/f34f184d10c049ef99aa7637cdc4ef04.txt

The file contents should just be the key itself:

f34f184d10c049ef99aa7637cdc4ef04

This makes the key accessible at https://yourdomain.com/f34f184d10c049ef99aa7637cdc4ef04.txt, which proves you own the domain.

Step 3: Create a submit utility

// lib/indexnow.ts
const INDEXNOW_KEY = process.env.INDEXNOW_API_KEY!;
const HOST = "https://hamidrazadev.com";

export async function submitToIndexNow(urls: string[]) {
  const response = await fetch("https://api.indexnow.org/indexnow", {
    method: "POST",
    headers: { "Content-Type": "application/json; charset=utf-8" },
    body: JSON.stringify({
      host: HOST,
      key: INDEXNOW_KEY,
      keyLocation: `${HOST}/${INDEXNOW_KEY}.txt`,
      urlList: urls,
    }),
  });

  if (!response.ok) {
    console.error("IndexNow submission failed:", response.status);
  }
}

Step 4: Call it when you publish content

// Example: after publishing a new blog post
await submitToIndexNow([
  "https://hamidrazadev.com/blog/my-new-post",
]);

You can submit up to 10,000 URLs per day per domain. For most blogs and apps, just calling this whenever you publish or update a page is more than enough.

Store your key in .env.local as INDEXNOW_API_KEY. Never hardcode it directly in your source files.

Part 7: Core Web Vitals & Performance Tips

Google uses Core Web Vitals as a direct ranking factor. Here's what matters:

LCP (Largest Contentful Paint) — how fast the main content loads.

Always use next/image and add priority to your hero image:

import Image from "next/image";

<Image src="/hero.png" alt="Hero" width={1200} height={630} priority />

CLS (Cumulative Layout Shift) — how much the layout jumps around.

Always define width and height for images. Reserve space for dynamic content like ads or embeds.

INP (Interaction to Next Paint) — how quickly the page responds to user input.

Minimize heavy client-side JavaScript. Use dynamic imports for non-critical components:

import dynamic from "next/dynamic";

const HeavyComponent = dynamic(() => import("@/components/HeavyComponent"), {
  ssr: false,
  loading: () => <p>Loading...</p>,
});

Font optimization:

import { Inter } from "next/font/google";

const inter = Inter({ subsets: ["latin"], display: "swap" });

next/font self-hosts Google Fonts and eliminates render-blocking font requests.

Best Tips & Do's and Don'ts

Do: Use semantic HTML. One <h1> per page. Use <article>, <main>, <section>, and <nav> properly. Google reads your HTML structure.

Do: Set canonical URLs on every page. This prevents duplicate content penalties when your page is accessible via multiple URLs.

Do: Write unique titles and descriptions for every page. Generic or duplicate metadata is one of the most common SEO mistakes and directly hurts rankings.

Do: Link internally. Every blog post should link to 2–3 related pages on your site. It helps Google understand your content structure and passes authority between pages.

Don't: Forget metadataBase in your root layout. Without it, all relative Open Graph image URLs will break.

Don't: Remove your DNS TXT record after verification. Google requires it to stay in place permanently. Removing it will de-verify your property.

Don't: Lazy-load images that are visible on first load. Only lazy-load content below the fold. Use priority for anything above the fold.

Don't: Block important pages in robots.txt by accident. Always double-check your disallow rules before deploying.

Common Mistakes to Avoid

Not submitting the sitemap after adding GSC.
Verifying your site doesn't automatically tell Google which pages exist. You need to submit /sitemap.xml separately in the Sitemaps section.

Using duplicate metadata across all pages.
Every page needs a unique title and description. Google can penalize or deprioritize pages with the same metadata as other pages on your site.

Forgetting metadataBase.
All relative Open Graph image paths break silently without it. This is the number one hidden bug in Next.js SEO setups.

Not validating structured data.
A small typo in your LD+JSON schema will cause Google to silently ignore it. Always run it through the Rich Results Test before publishing.

Skipping Bing entirely.
Bing powers DuckDuckGo, Yahoo, and Microsoft Edge search. It also feeds some AI chatbot search results. It only takes five minutes to set up via the GSC import — don't skip it.

Requesting indexing too aggressively.
There's a daily quota on "Request Indexing" in Google Search Console. Use it for important pages, not every small update. For bulk updates, submit your sitemap instead.

Deploying without testing verification methods.
After adding your Google/Bing verification meta tags to Next.js, deploy and check view-source:yourdomain.com to confirm the tags are actually rendering in the HTML before you click "Verify" in either console.

Conclusion

Getting your Next.js app properly set up for SEO is a multi-step process — but each step is straightforward when you know what you're doing.

Here's the full checklist:

✅ Set up Metadata API with titles, descriptions, Open Graph, and Twitter cards
✅ Add LD+JSON structured data for blog posts, FAQs, and site info
✅ Generate a dynamic sitemap.xml and robots.txt
✅ Verify your site in Google Search Console (DNS TXT is most reliable)
✅ Submit your sitemap to Google
✅ Add to Bing Webmaster Tools — import from GSC for instant setup
✅ Submit sitemap to Bing too
✅ Use URL Inspection to check indexing status and request indexing for key pages
✅ Set up IndexNow to notify Bing about new content instantly
✅ Optimize Core Web Vitals using next/image, next/font, and dynamic imports

None of this is complicated on its own. The trick is doing all of it together. When everything is in place, Google and Bing can find your pages, understand them, and rank them — and that's when the real traffic starts flowing. 🚀

Got questions or something that helped you? Drop a comment below. And if you want more practical guides like this one, there's a lot more waiting for you at hamidrazadev.com — see you there. 😊

VS Code Tips and Tricks That Will Seriously Boost Your Developer Experience

Muhammad Hamid Raza — Sat, 18 Apr 2026 17:05:31 +0000

You open VS Code, stare at your editor, and start typing. Same workflow, same shortcuts, same frustration when something takes longer than it should. Sound familiar? 😅

VS Code is probably the most popular code editor on the planet right now — and for good reason. It's fast, flexible, and packed with features. But most developers only use maybe 20% of what it actually offers. The other 80%? It's just sitting there, waiting to save you hours every week.

Whether you've been using VS Code for years or just installed it last week, there are always small tweaks and hidden features that make the experience feel smoother, faster, and honestly — a lot more enjoyable.

So here's the question: what if your editor could work for you instead of just being a window you type code into?

What Is "Developer Experience" in VS Code?

Developer experience (DX) is exactly what it sounds like — how enjoyable, efficient, and smooth your day-to-day coding feels.

Think of it like a kitchen. A good kitchen has everything in the right place. Your tools are sharp, the layout makes sense, and you can cook without bumping into stuff. A bad kitchen? You're hunting for utensils, the stove is too far from the sink, and somehow you always burn the pasta.

VS Code is your kitchen. The tips in this post help you organize it so everything is right where you need it.

Why This Matters for Everyday Development

Bad DX kills momentum. When your editor slows you down — slow search, messy file navigation, no snippets, zero shortcuts — you break your flow constantly.

And flow is everything in development. Once you lose it, getting it back takes time.

Improving your VS Code setup is not about being fancy. It's about removing friction. When your editor feels natural and responsive, you write better code, debug faster, and ship more confidently.

The Tips and Tricks That Actually Help 🚀

1. Master the Command Palette

Press Ctrl + Shift + P (or Cmd + Shift + P on Mac). That's it. That's your superpower.

The Command Palette gives you access to literally every VS Code feature — without touching your mouse. You can open settings, install extensions, run tasks, change themes, and more. If you're not using this daily, you're leaving speed on the table.

2. Use Multi-Cursor Editing

Need to rename the same variable in five places at once? Don't do it one by one like it's 2005.

Alt + Click (or Option + Click on Mac) to place multiple cursors wherever you want.
Ctrl + D to select the next occurrence of the highlighted word and edit them all at once.

This one trick alone can shave serious time off repetitive edits.

3. Open Files Instantly with Quick Open

Press Ctrl + P and start typing the filename. VS Code fuzzy-searches your project and opens it almost instantly.

No folder-diving. No sidebar scrolling. Just type and go. ⚡

4. Set Up a Good Font and Theme

This sounds cosmetic, but it genuinely affects how long you can comfortably code.

Fira Code and JetBrains Mono are developer favorites with built-in ligatures (those little symbols where => and !== look cleaner).
A good dark theme like One Dark Pro, Catppuccin, or Dracula Official reduces eye strain during long sessions.

Go to settings and enable "editor.fontLigatures": true if your font supports it.

5. Create and Use Code Snippets

If you type the same boilerplate code every day, it's time to automate it.

VS Code lets you create custom snippets. For example, you can type rfc and have it expand into a full React functional component skeleton instantly.

Go to File → Preferences → Configure User Snippets, pick your language, and add your own. It takes ten minutes to set up and saves you hours over time.

6. Split Editor and Work in Parallel

Press Ctrl + \ to split your editor into two panels. Now you can have your component file on the left and its CSS on the right. Or your frontend code and API response side by side.

This is one of those things that sounds small until you actually start using it every day. 👀

7. Use the Integrated Terminal Properly

You don't need to leave VS Code to run your commands. Press Ctrl + ` to open the integrated terminal.

Better yet — you can open multiple terminals at once using the + button in the terminal panel. One for your dev server, one for Git, one for npm commands. No more Alt-Tabbing between windows.

8. Enable Auto Save

Go to File → Auto Save and turn it on. Done.

You will never again lose changes because you forgot to hit Ctrl + S. It's one of the simplest but most underrated quality-of-life improvements in VS Code.

9. Use Peek Definition Instead of Jumping Around

Instead of opening a new file to check a function definition, press Alt + F12. VS Code shows the definition right inline without leaving your current file.

Use F12 if you actually want to navigate to it. Use Ctrl + Click for the same. But Peek is perfect when you just want a quick look.

10. Customize Keyboard Shortcuts

VS Code lets you remap any shortcut to whatever feels natural to you.

Go to File → Preferences → Keyboard Shortcuts and search for any action. If the default shortcut feels awkward, change it. Your setup should match you, not the other way around.

11. Use GitLens Extension for Better Git Workflows

GitLens is a free extension that supercharges the built-in Git features. It shows you who changed a line and when — right inside the editor, inline.

No more guessing who wrote that mysterious block of code. You'll know exactly when it was added and why (if the commit message was decent 😄).

12. Turn on Bracket Pair Colorization

Deeply nested code is hard to read. VS Code has a built-in feature that colors matching brackets differently so you can instantly see which bracket belongs to which block.

Enable it in settings:

"editor.bracketPairColorization.enabled": true

It's a small visual tweak that makes a real difference in readability.

13. Use Workspaces for Multi-Project Work

If you're working on multiple related repos, a VS Code Workspace lets you open all of them together in one window with shared settings.

Go to File → Save Workspace As and configure your folders. It keeps everything organized without opening a dozen separate windows.

14. Zen Mode for Deep Focus

Press Ctrl + K Z to enter Zen Mode. Everything disappears — sidebar, status bar, tabs. Just you and your code.

When you need to focus on a tricky problem without distractions, this mode is genuinely helpful.

Quick Comparison: Without vs. With These Tips

Situation	Without the Tips	With the Tips
Opening a file	Clicking through the sidebar	`Ctrl + P` and done in 1 second
Renaming a variable in 10 places	Edit one by one	Multi-cursor in seconds
Running terminal commands	Alt-Tab to a separate terminal	Integrated terminal in the same window
Checking a function definition	Navigating to a different file	Peek Definition inline
Tracking code changes	Guessing or checking Git log	GitLens shows it inline

Best Tips / Do's and Don'ts ✅

Do:

Take 10 minutes to set up custom snippets for your most-used code patterns.
Learn at least five keyboard shortcuts this week. Just five.
Install only the extensions you actually need. Don't hoard them.
Use the Command Palette when you don't know a shortcut — it teaches you shortcuts over time.
Keep your settings synced across machines using VS Code's built-in Settings Sync.

Don't:

Don't install 30 extensions and wonder why VS Code is slow.
Don't ignore the built-in features just because you haven't explored them.
Don't use your mouse for things a shortcut can do in one keystroke.
Don't skip font and theme setup — your eyes will thank you during late-night sessions.

Common Mistakes Developers Make with VS Code

Installing too many extensions
This is the number one performance killer. Every extension adds a little overhead. Install only what you use regularly. Review and uninstall the ones you haven't touched in months.

Never touching the settings
VS Code's default settings are okay, but they're not optimized for you. Spending 15 minutes in settings.json can dramatically improve your experience. Things like tab size, word wrap, format on save — these matter daily.

Ignoring keyboard shortcuts
Developers who rely entirely on their mouse spend significantly more time on repetitive tasks. You don't need to memorize every shortcut. Start with the ten most useful ones and build from there.

Not using version control inside VS Code
The built-in Source Control panel is actually great. Many beginners jump out to a separate Git client when VS Code already handles staging, committing, and branching quite well.

Not syncing settings across devices
If you work on multiple machines and you're not using Settings Sync, you're setting up VS Code from scratch every time. Turn it on under Accounts → Settings Sync and save yourself the hassle.

Wrapping Up 💡

VS Code is already a great editor. But with the right setup, it becomes your editor — one that matches how you think and work.

You don't need to implement all of these today. Pick three things from this list, try them for a week, and see how they feel. Then add more when you're ready.

The goal isn't to become a VS Code power user overnight. The goal is to slowly remove the little friction points that interrupt your flow — until coding feels genuinely smooth and enjoyable.

Because when your tools feel good, your work feels good too.

If you found this helpful, there's a lot more where this came from. Check out more dev tips, tools breakdowns, and tutorials at hamidrazadev.com — a blog built specifically for developers who want to keep leveling up.

Share this post with a developer friend who's still clicking through their sidebar one folder at a time 😄. And if you've got a VS Code tip that changed your workflow, drop it in the comments — let's build the list together.

From BSOD to Dev Workstation: How I Rebuilt My PC the Right Way (And Learned a Ton Doing It)

Muhammad Hamid Raza — Fri, 17 Apr 2026 04:53:22 +0000

You know that feeling when your computer is stuck in a loop, crashing over and over, and you're sitting there thinking "why does this exist"? 😤

Yeah. That was me. Blue screen. Reboot. Blue screen. Reboot. A cycle of pure suffering.

But here's the thing — that disaster turned into one of the best learning experiences I've had as a developer. I went from crying over a broken machine to understanding system architecture, disk management, and package management like a proper engineer.

If you've ever been in that situation — or if you just want to know how to set up a clean, resilient developer workstation from scratch — this one's for you.

What Actually Happened (Phase 1: The Patched Nightmare)

My HP Compaq was stuck in a BSOD loop. The culprit? A "patched" version of Windows 11 that someone had modified to bypass hardware checks.

It seemed smart at the time. Skip the TPM requirements, skip the Secure Boot checks, save time. Right?

Wrong.

Every install attempt crashed with ACPI.sys errors. Then came the real gut punch: error 0x80070570 — which basically means the install files themselves were corrupt. The "shortcut" version of Windows was actually a ticking time bomb.

Here's the lesson I didn't know I needed:

Patched or modified Windows installers are not shortcuts. They are the longest, most painful road to failure.

The files are corrupt. The registry gets messy. Drivers behave weirdly. And you will spend 10x more time debugging than you would have spent just doing it right from the start.

The Turning Point (Phase 2: The Senior Dev Rebuild)

We stopped chasing quick fixes and decided to do it properly. This is where things actually started moving forward.

Step 1: Get a legitimate Windows ISO

Downloaded a clean Windows 11 ISO directly from Microsoft. No torrents. No "activator" versions. Just the real thing.

Step 2: Use Rufus the right way

Rufus is a free tool that creates bootable USB drives. But the real magic? It can bypass TPM 2.0 and Secure Boot requirements for older machines — legally and cleanly, without touching the installer itself.

For older hardware like HP Compaq machines, this is a lifesaver. Rufus handles the bypass at the image level, so the installed Windows stays clean and stable.

Step 3: The nuclear option — diskpart

This was the most important step. Before installing Windows, I booted into the installer, opened Command Prompt with Shift + F10, and ran:

diskpart
list disk
select disk 0
clean

The clean command wiped everything off the SSD. Every partition. Every trace of the patched version.

Starting with a completely clean disk meant no leftover corrupt files, no ghost partitions, no weird driver conflicts. It felt scary at first, but it was exactly the right call.

Why a Clean Install Matters More Than You Think

A lot of people upgrade Windows over an existing install, or they let a patched version "update" itself. Here's why that's a problem:

Corrupt files carry over. Old errors don't disappear — they just hide.
Driver conflicts build up. Especially on HP machines with specific hardware.
The registry becomes a mess. Unused entries stack up and slow everything down.
Security holes stay open. Patched installs often disable Windows Defender and other protections silently.

A clean slate isn't just about speed. It's about having a system you can actually trust.

Victory and Optimization (Phase 3: Building the Dev Setup)

Once Windows was installed cleanly, the real work began. A fresh Windows install is just a starting point — not a workstation.

🖥️ Drivers: Do It Manually

The first instinct after a fresh install is to grab something like Driver Booster and let it "auto-install everything." Don't.

Third-party driver tools are notorious for installing outdated or generic drivers that cause more problems than they solve. Instead:

Find your exact hardware model (HP Compaq with Intel HD Graphics 2500 in this case).
Go to Intel's official website or the HP support page.
Download the exact driver for your hardware and Windows version.

After installing the correct Intel HD Graphics 2500 driver manually, the GPU correctly recognized 1.7GB of shared memory — which matters a lot for design work and running modern web UIs smoothly.

⚡ PowerShell 7 + Chocolatey

This is where things got genuinely fun.

PowerShell 7 is a massive upgrade from the default Windows PowerShell. It's cross-platform, faster, and far more capable.

Chocolatey (choco) is a package manager for Windows — think of it like apt on Linux or brew on macOS. Instead of clicking through installer wizards, you install software with a single command:

choco install nodejs-lts
choco install git
choco install vscode

Done. Clean. No random checkboxes offering you browser toolbars. No manual updates. Just software installed the way developers like it.

This is one of those tools that, once you start using it, you wonder how you ever lived without it.

✅ Official Installs Only

VS Code and Chrome were installed through their official installers (or Chocolatey), not through sketchy third-party sites. This keeps the Windows registry clean and ensures you're getting the actual software without bundled garbage.

The Recovery Plan: Lahore-Proofing Your Machine 🛡️

Here's something nobody talks about in Western developer tutorials: load shedding is real, and it will corrupt your Windows install if you're not careful.

A sudden power cut during a Windows update, a driver install, or even just heavy disk activity can corrupt system files. I've seen it happen. So we built a three-layer protection plan.

Layer 1: System Restore Point

A System Restore Point is your "Undo" button. If something breaks after a driver install or a Windows update, you can roll back to this exact moment without losing your files.

How to create one:

Search for "Create a restore point" in the Start menu.
Select your C: drive and click "Configure" → "Turn on system protection."
Click "Create" and give it a name like "Fresh Setup - Clean Install."

Do this right after every major change to your system.

Layer 2: System Image Backup

A System Restore Point is great for small issues. But if your SSD completely fails or gets corrupted beyond repair, you need a full backup.

A System Image copies your entire C: drive — Windows, drivers, installed software, settings — onto another drive. Think of it as your "Insurance Policy."

How to create one:

Go to Control Panel → Backup and Restore (Windows 7).
Click "Create a system image."
Save it to your 250GB HDD (external or secondary drive).

If disaster strikes, you can restore the entire system from this image in minutes instead of hours.

Layer 3: Cloud and GitHub Sync

No matter how good your local backups are, they're useless if the whole machine is stolen, flooded, or physically destroyed.

For a Next.js developer with active projects:

GitHub for all code. Push regularly. Use private repos for sensitive projects.
Google Drive or OneDrive for ICS notes, PDFs, and documents.
VS Code Settings Sync (built-in) to back up your extensions and editor config.

These three layers mean you can lose the entire machine and be back to full productivity within an hour.

Key Lessons That Actually Stick

Let's be honest — the best lessons come from the worst experiences. Here's what this whole journey taught me:

💡 Shortcuts usually cost you more time, not less. The patched Windows was supposed to save 20 minutes. It cost days of debugging.

💡 Clean installs are non-negotiable. If something is deeply broken, wipe it and start fresh. Fighting corrupt systems is a losing battle.

💡 Manual driver installs beat auto-driver tools. Know your hardware. Install only what you need, from the official source.

💡 Package managers are a superpower. Once you start managing software through Chocolatey (or winget), you'll never go back to clicking through wizard installers.

💡 Backups are not optional. Especially if you're working in an area with unstable power. One bad outage can ruin weeks of work.

💡 The "right way" isn't the hard way. It just feels harder at the start because it's unfamiliar. But it saves you from exponentially bigger problems later.

Common Mistakes People Make During Windows Setup

These are the traps that catch most beginners — and some experienced people too:

❌ Using modified or "lite" Windows ISOs. They corrupt easily, disable security features, and cause random driver issues. Always use official ISOs.

❌ Skipping the disk clean before install. Leftover partitions and old files cause weird conflicts. Use diskpart clean for a true fresh start.

❌ Installing every driver with Driver Booster or similar tools. These tools inject outdated and generic drivers. Install manually from official sources.

❌ Skipping system backups because "nothing has gone wrong yet." That's exactly when disasters happen — before you're prepared.

❌ Installing random software from unverified sites. Your registry fills up, startup times increase, and security risks multiply. Use Chocolatey, winget, or official sites only.

❌ Not setting up cloud sync for active projects. Local backups are great, but they don't protect against hardware failure or theft. GitHub is free. Use it.

Conclusion

What started as a total disaster — a BSOD loop, corrupt files, and a lot of frustrated emojis — turned into a genuinely valuable learning experience.

The machine that once couldn't even boot is now a clean, fast, developer-ready workstation. It has proper drivers, a modern terminal, a package manager, and three layers of backup protection built specifically for the power grid realities of Lahore.

More importantly, the process taught something that no tutorial can rush: understanding why each step matters, not just following instructions blindly.

If your machine is acting up, or if you just want to set up a clean developer environment from scratch, follow the process above. It's not glamorous, but it works — and you'll understand your own system far better for it. 🔧

Want more practical, no-fluff developer content? Check out hamidrazadev.com for more posts like this. And if this helped you, feel free to share it — there's definitely another developer out there stuck in a BSOD loop who needs it. 🚀

OpenRouter vs Hugging Face: Which One Should You Actually Use?

Muhammad Hamid Raza — Mon, 13 Apr 2026 07:53:31 +0000

So you've been exploring AI tools, and now you're staring at two names that keep showing up everywhere — OpenRouter and Hugging Face. Both sound important. Both involve AI models. And both have enough features to make your head spin if you try to compare them too fast.

Here's the thing though: asking "which one is better" is like asking whether a highway is better than a factory. They're not really competing — they're doing different jobs. But once you understand what each one does, the choice becomes obvious. 😊

Let's break it all down.

What Is OpenRouter?

OpenRouter is essentially a universal API gateway for AI models. Think of it like a single remote control that works with every TV in the house.

Instead of signing up for OpenAI, then Anthropic, then Google, then managing three different API keys, three billing dashboards, and three different code setups — you just use OpenRouter. One API key. One endpoint. Access to models from all of them.

It uses an OpenAI-compatible API format, which means if you've already written code for GPT-4, switching to Claude or Gemini is just a one-line change.

It also has a handy Playground where you can send the same prompt to multiple models at once and compare their responses side by side in real time. That alone saves hours of manual testing.

What Is Hugging Face?

Hugging Face is something much bigger — it's the GitHub of AI models.

It hosts hundreds of thousands of pre-trained models for text, images, audio, and more. It has community discussions, leaderboards, trending models, research papers, and even compute options for running your own models. It's where developers go to find, explore, test, and download AI models.

It also provides tools like the Transformers library (one of the most popular ML libraries in the world), datasets, model training notebooks, and infrastructure for deploying your own models.

If you want to explore the open-source AI ecosystem — Llama variants, Qwen, DeepSeek, fine-tuned niche models — Hugging Face is where you go first.

Why This Comparison Actually Matters

If you're a developer building an AI-powered app, this decision affects three things directly:

How fast you ship — Managing multiple API integrations slows you down.
How much you spend — Model costs vary wildly across providers.
How much control you have — Some use cases need open-source models you can self-host.

Getting this right early saves you from painful refactors later. 🔧

Key Differences: OpenRouter vs Hugging Face

Feature	OpenRouter	Hugging Face
Primary purpose	Multi-model API gateway	Model hub & ML ecosystem
Model access	Frontier models (GPT, Claude, Gemini, etc.)	Open-source & community models
API support	Yes, OpenAI-compatible	Yes, Inference API + Endpoints
Free tier	Yes (limited credits)	Yes (free Inference API)
Self-hosting	No	Yes (download & run locally)
Community & research	No	Very active
Best for	App developers, API users	Researchers, ML engineers

Benefits With Real-Life Examples

✅ OpenRouter — Great for App Developers

One API for everything — Building a chatbot? You can start with a free open-source model, then upgrade to Claude or GPT-4 for production, all without touching your codebase.
Cost optimization — OpenRouter lets you route to the cheapest provider that meets your latency requirements. Great when you're running thousands of API calls per day.
Side-by-side model testing — Use the Playground to compare Claude 3 vs Gemini 1.5 vs Mistral on your exact use case before committing.
Minimal setup — If you already know the OpenAI SDK, you're basically already set up.

✅ Hugging Face — Great for ML Engineers & Researchers

Model discovery — Need a small, fast embedding model? A specialized medical NLP model? There are thousands of community-trained models waiting.
Open-source freedom — Download the model, run it on your own server, modify it, fine-tune it. Full control.
Transformers library — One of the most used libraries in ML. Works with PyTorch and TensorFlow. Makes loading and running models simple.
Inference Endpoints — Don't want to manage GPU servers yourself? Hugging Face lets you deploy a model with dedicated compute, priced per hour.

OpenRouter vs Hugging Face: When to Use Which

Here's the honest, practical breakdown:

Use OpenRouter when:

You're building an app and need quick, flexible access to frontier models
You want to switch between GPT, Claude, Gemini, and others without code changes
You want cost routing and don't want to manage multiple billing accounts
You just need a reliable API and don't care about the underlying infrastructure

Use Hugging Face when:

You want to explore or download open-source models
You're doing ML research or model fine-tuning
You need a specialized model (text classification, image captioning, speech-to-text, etc.)
You want full control over the model and your data
You're building ML pipelines using the Transformers or Datasets libraries

Use both when:

You want to browse and pick a model on Hugging Face, then deploy it via an Inference Endpoint or run it locally with Ollama — while also using OpenRouter to access frontier models in the same app.

This is actually a very common setup in 2026. They complement each other well.

Tips for Making the Right Choice

💡 Start with your use case, not the tool. Are you calling AI for text generation in an app? OpenRouter. Training or exploring models? Hugging Face.

💡 Don't overcomplicate early on. If you're building your first AI feature, OpenRouter's simplicity wins. Get the app working first.

💡 Check the free tiers first. Both platforms have free usage. Test before you commit money.

💡 Think about data privacy. If your data is sensitive, open-source models on Hugging Face (run locally) keep data off third-party servers. OpenRouter routes through provider APIs, so understand the data policies of each model.

💡 Use the Playground. OpenRouter's side-by-side model testing is genuinely useful when you're trying to pick the right model for a task.

Common Mistakes Developers Make

❌ Treating them as direct competitors
They're not. One is an API layer, the other is a model ecosystem. You can absolutely use both.

❌ Using Hugging Face's free Inference API in production
The free API tier on Hugging Face is for testing, not production workloads. It has rate limits and no uptime guarantees. If you're shipping a product, use Inference Endpoints or a proper provider.

❌ Assuming OpenRouter hosts its own models
It doesn't. OpenRouter is a routing layer — it sends your requests to the actual model providers (OpenAI, Anthropic, Google, etc.). The performance and output you get is from those underlying providers.

❌ Ignoring costs
Model pricing varies a lot across providers. OpenRouter makes this visible and comparable, which is genuinely useful. Always check the pricing page before picking a model for a high-volume use case.

❌ Not reading the model card on Hugging Face
Every model on Hugging Face has a model card explaining its intended use, limitations, and training data. Skipping it is a mistake, especially if you're picking a model for a specific industry or sensitive use case.

Final Verdict

So — which is better?

Neither. And both. It depends entirely on what you're trying to do.

OpenRouter is your best friend if you're a developer who wants fast, flexible, low-maintenance access to top AI models through a single API. It's clean, practical, and built for shipping.

Hugging Face is your best friend if you want to explore, experiment, research, or run open-source models with full control. It's the world's largest AI model community, and there's nothing else quite like it.

Most experienced developers end up using both — OpenRouter for production API calls, Hugging Face for model discovery and open-source experimentation.

Start with the one that fits your current project. You'll probably end up using both eventually. 🚀

If this helped you think more clearly about your AI tooling setup, check out more practical developer guides at hamidrazadev.com. There's always something useful brewing there. 😊

How to Use Claude Code with OpenRouter — Run Any AI Model for Free or Cheap 🚀

Muhammad Hamid Raza — Sun, 12 Apr 2026 07:37:25 +0000

Ever wished you could use Claude Code with models other than just the official Anthropic ones? Maybe you want to try a powerful free model, cut costs, or experiment with something new like NVIDIA's Nemotron?

Good news — it's totally possible. Claude Code supports custom API base URLs, which means you can point it to OpenRouter and instantly unlock access to dozens of AI models, including free ones. 💡

In this guide, I'll walk you through the complete setup on Windows, macOS, and Linux — step by step, no fluff.

What Is OpenRouter?

OpenRouter is a unified API gateway that gives you access to many AI models — from OpenAI and Anthropic to Google, Meta, Mistral, NVIDIA, and more — all through a single API endpoint.

Think of it like a TV remote that controls every streaming platform. Instead of managing separate API keys for each provider, you get one key that works everywhere.

Some models on OpenRouter are completely free. Others cost a fraction of what you'd pay directly. It's a great way to experiment without burning through credits.

Why Use Claude Code with OpenRouter?

Claude Code is a powerful AI coding assistant that runs in your terminal. By default, it talks directly to Anthropic's API. But since it supports environment variable overrides, you can redirect it to any OpenAI-compatible endpoint — including OpenRouter.

Reasons you might want to do this:

💸 You want to use a free model to save money
🧪 You want to experiment with different models for different tasks
🌐 You already have OpenRouter credits and don't want to maintain two separate accounts
⚡ You want to try newer open-source models like NVIDIA Nemotron, Llama, Qwen, etc.

What You'll Need

Before we start, make sure you have:

✅ Claude Code installed — via npm install -g @anthropic-ai/claude-code
✅ An OpenRouter account — sign up free at openrouter.ai
✅ Your OpenRouter API key — get it from the OpenRouter dashboard under "API Keys"
✅ A model name from OpenRouter you want to use (e.g., nvidia/nemotron-3-super-120b-a12b:free)

Where Is the Settings File?

Claude Code reads its configuration from a settings.json file. Here's where to find it depending on your OS:

Operating System	Settings File Path
Windows	`C:\Users\<YourUsername>\.claude\settings.json`
macOS	`~/.claude/settings.json`
Linux	`~/.claude/settings.json`

If the file doesn't exist yet, just create it. Claude Code will pick it up automatically.

Step-by-Step Setup

🪟 Windows

Step 1: Open File Explorer and navigate to:

C:\Users\<YourUsername>\.claude\

Replace <YourUsername> with your actual Windows username.

Step 2: If the .claude folder doesn't exist, create it manually.

Step 3: Inside that folder, open or create settings.json using Notepad or VS Code.

Step 4: Paste the following configuration:

{
  "env": {
    "ANTHROPIC_BASE_URL": "https://openrouter.ai/api",
    "ANTHROPIC_AUTH_TOKEN": "your-openrouter-api-key-here",
    "ANTHROPIC_API_KEY": "",
    "ANTHROPIC_DEFAULT_SONNET_MODEL": "nvidia/nemotron-3-super-120b-a12b:free"
  }
}

Step 5: Replace your-openrouter-api-key-here with your actual OpenRouter API key.

Step 6: Save the file and open a new terminal. Run:

claude

You're done! 🎉

🍎 macOS

Step 1: Open Terminal.

Step 2: Navigate to the .claude folder:

cd ~/.claude

If it doesn't exist yet, create it:

mkdir -p ~/.claude

Step 3: Open or create the settings file using your preferred editor:

nano ~/.claude/settings.json
# or
code ~/.claude/settings.json

Step 4: Paste this configuration:

{
  "env": {
    "ANTHROPIC_BASE_URL": "https://openrouter.ai/api",
    "ANTHROPIC_AUTH_TOKEN": "your-openrouter-api-key-here",
    "ANTHROPIC_API_KEY": "",
    "ANTHROPIC_DEFAULT_SONNET_MODEL": "nvidia/nemotron-3-super-120b-a12b:free"
  }
}

Step 5: Replace your-openrouter-api-key-here with your real key.

Step 6: Save and close. Then open a new terminal window and run:

claude

That's it for macOS! 🍏

🐧 Linux

Step 1: Open your terminal.

Step 2: Navigate to (or create) the .claude directory:

mkdir -p ~/.claude && cd ~/.claude

Step 3: Create or edit the settings file:

nano ~/.claude/settings.json
# or
vim ~/.claude/settings.json

Step 4: Paste the configuration:

{
  "env": {
    "ANTHROPIC_BASE_URL": "https://openrouter.ai/api",
    "ANTHROPIC_AUTH_TOKEN": "your-openrouter-api-key-here",
    "ANTHROPIC_API_KEY": "",
    "ANTHROPIC_DEFAULT_SONNET_MODEL": "nvidia/nemotron-3-super-120b-a12b:free"
  }
}

Step 5: Replace the API key placeholder with your real OpenRouter key.

Step 6: Save the file. Open a fresh terminal session and run:

claude

Linux users, you're set! 🐧

Understanding the Configuration Fields

Here's what each field in the config actually does:

Field	Purpose
`ANTHROPIC_BASE_URL`	Tells Claude Code to use OpenRouter's API instead of Anthropic's
`ANTHROPIC_AUTH_TOKEN`	Your OpenRouter API key used for authentication
`ANTHROPIC_API_KEY`	Left empty intentionally — OpenRouter handles auth via the token
`ANTHROPIC_DEFAULT_SONNET_MODEL`	The model you want Claude Code to use by default

The ANTHROPIC_DEFAULT_SONNET_MODEL field is where the magic happens. Change this to any model ID from OpenRouter's model list and Claude Code will use it.

How to Find Model IDs on OpenRouter

Go to openrouter.ai/models
Browse or search for the model you want
Click on it to see the model ID
Copy the full model string (e.g., meta-llama/llama-3.3-70b-instruct:free)
Paste it as the value of ANTHROPIC_DEFAULT_SONNET_MODEL

Models with :free at the end are completely free to use — no credits needed. 👀

Pros and Cons

✅ Advantages of Using Claude Code with OpenRouter

Access to free models — great for learning and experimenting
One API key for many models
Flexibility to switch models without reinstalling anything
Works with open-source models that Anthropic doesn't offer
Useful if you're on a budget but still want powerful coding assistance

⚠️ Things to Be Aware Of

Not every OpenRouter model is as capable as Claude Sonnet or Opus
Free models sometimes have rate limits or slower response times
Some models may not follow Claude Code's system prompts as precisely
If the model doesn't support tool use well, Claude Code's agentic features may behave unexpectedly

Best Tips

✅ Do this:

Always test your setup with a simple prompt first before using it on a real project
Use free models for low-stakes tasks like drafting, explaining code, or answering questions
Keep your API key private — never commit settings.json to a public Git repo
Check the OpenRouter model card for context window size before using a model on large codebases

❌ Avoid this:

Don't leave your real API key in shared machines or public repositories
Don't assume every model will behave exactly like Claude — each model has its own strengths and quirks
Don't set ANTHROPIC_API_KEY to your actual Anthropic key when using OpenRouter — it's not needed and might cause confusion

Common Mistakes People Make

1. Wrong API base URL format

Some people accidentally set the URL to https://openrouter.ai/api/v1. The correct value is https://openrouter.ai/api — Claude Code appends /v1/messages automatically.

2. Leaving the model name blank or wrong

If ANTHROPIC_DEFAULT_SONNET_MODEL is missing or has a typo, Claude Code may fall back to an unexpected default or throw an error. Always double-check the model ID from OpenRouter's model list.

3. Using an expired or invalid API key

OpenRouter keys are easy to rotate. If Claude Code starts returning auth errors, go to your OpenRouter dashboard and create a fresh API key.

4. Not restarting the terminal

Settings are read when Claude Code starts. If you edit settings.json while Claude Code is running, the changes won't apply until you restart your terminal.

5. Committing the settings file to Git

This one hurts. Your settings.json contains your API key. Add .claude/ to your .gitignore to avoid accidentally pushing it to a public repository.

Conclusion

Setting up Claude Code with OpenRouter is genuinely simple once you know where the settings file lives. A few lines of JSON and you unlock access to a wide range of AI models — including free ones — all from your existing terminal workflow.

Whether you're on Windows, macOS, or Linux, the process is essentially the same: find the settings file, drop in the config, and you're good to go. 🔧

The best part? You can switch models anytime just by changing one line. That kind of flexibility is rare and genuinely useful for anyone who codes with AI tools regularly.

If this guide helped you, I'd love it if you shared it with a fellow developer who's been curious about Claude Code but didn't want to deal with API costs. And if you're looking for more practical dev guides like this, check out 👉 hamidrazadev.com — there's a lot more where this came from.

Happy coding! 😊

WSL Explained: Why Windows Developers Are Obsessed With It 🐧

Muhammad Hamid Raza — Fri, 10 Apr 2026 16:56:16 +0000

Have you ever been a Windows user who secretly envied Linux developers? You know — the ones who casually run a one-liner in the terminal and get everything working in seconds while you're still fighting with PATH variables and permission errors?

That was the daily reality for a lot of Windows developers. Until WSL came along and changed everything.

WSL — short for Windows Subsystem for Linux — is one of the most genuinely useful tools Microsoft has shipped in years. It lets you run a full Linux environment directly inside Windows, no dual-boot, no virtual machine, no hassle.

So what exactly is it? Why should you care? And is it really as helpful as people say?

Let's find out. 👇

What Is WSL?

Think of WSL as a translation layer built into Windows. It lets your Windows machine speak "Linux" fluently.

Here's a simple way to think about it: imagine you're in an English-speaking office, but your best collaborator speaks French. Instead of flying to France or hiring a full-time translator (that's a VM), you install a small translation app on your computer (that's WSL). Now you can communicate instantly without switching desks.

WSL does the same thing for your system. You can open a terminal, type Linux commands, run Linux tools, and work with Linux file systems — all without leaving Windows.

There are two versions:

WSL 1 — the original, which translates Linux calls into Windows calls
WSL 2 — the current version, which runs a real Linux kernel inside a lightweight virtual machine. It's faster, more compatible, and what most people use today

You can install popular distros like Ubuntu, Debian, Kali Linux, or Fedora directly from the Microsoft Store.

Why WSL Matters for Developers

Here's a real situation many Windows developers have faced:

You're following a tutorial. The instructor is on macOS or Linux. They run a command. It works perfectly. You try the same command on Windows. Error. You try the Windows equivalent. Different error. You spend 45 minutes on Stack Overflow. You feel like giving up.

WSL fixes that.

Most open-source tools, frameworks, and documentation are written with Linux/macOS in mind. Bash scripts, package managers like apt, native Node.js and Python setups, Docker, and backend development workflows all behave much more smoothly on Linux.

With WSL, you get that same smooth experience without leaving Windows. Your files, apps, and everything else stay exactly where they are.

Benefits of WSL with Real-Life Examples

✅ Run Linux Commands on Windows

Before WSL, running grep, sed, awk, or shell scripts on Windows required workarounds or third-party tools. Now you just open your Ubuntu terminal in WSL and type them directly.

Example: A developer automating file renaming across hundreds of files uses a simple Bash one-liner that would take a full PowerShell script to replicate.

✅ No Dual-Boot Headaches

Setting up dual boot is time-consuming, risky, and annoying to manage. You have to restart your machine every time you want to switch. WSL eliminates that entirely.

Example: A student learning Linux commands for a university course uses WSL on their Windows laptop without ever partitioning their hard drive.

✅ Use Linux Dev Tools Natively

Tools like make, gcc, curl, git, vim, and dozens of others work out of the box in WSL. No emulation, no compatibility layer workarounds.

Example: A backend developer compiles a C++ project using g++ inside WSL the same way it would work on a Linux server in production.

✅ Faster and Lighter Than a Virtual Machine

Running a full VM like VirtualBox or VMware takes a lot of RAM and CPU. WSL 2 uses a lightweight virtual machine that starts in seconds and uses a fraction of the resources.

Example: A developer on a mid-range laptop who previously crashed their VM regularly now runs WSL without any performance issues.

✅ Seamless File Access Between Windows and Linux

With WSL, you can access your Windows files from Linux and your Linux files from Windows Explorer. Both systems talk to each other comfortably.

Example: You write code in VS Code on Windows, and that code lives in your Linux file system via WSL. Both sides see it perfectly.

✅ Works Great With VS Code

With the Remote - WSL extension in VS Code, you can open a WSL folder in VS Code as if it were a native Linux environment. The editor runs on Windows but the code runs in Linux.

Example: A full-stack developer uses VS Code on Windows with a Node.js project inside WSL. It feels exactly like working on a Linux machine.

✅ Docker Integration

Docker Desktop on Windows integrates directly with WSL 2. This means containers run faster and more reliably compared to the old Hyper-V backend.

Example: A developer running a multi-container app with Docker Compose sees noticeably faster build times after switching to the WSL 2 backend.

WSL vs Full Virtual Machine — What's the Difference?

Feature	WSL 2	Full VM (VirtualBox / VMware)
Startup time	Seconds	Minutes
RAM usage	Low	High
File access	Shared with Windows	Separate disk
Installation	Simple (one command)	Manual setup needed
Performance	Near-native	Slower
GUI support	Supported (WSLg)	Full GUI always
Best for	Dev work, CLI tools	Full isolated environments

For most developers doing everyday development work, WSL 2 wins easily. A full VM is still useful when you need a completely isolated environment, but for coding, scripts, and tools, WSL is the better choice.

Best Tips for Using WSL

💡 Use WSL 2, not WSL 1. WSL 2 has better file I/O performance, full system call compatibility, and Docker support. Always prefer it.

💡 Store your project files inside the Linux file system. When you keep files at /home/yourname/projects instead of /mnt/c/Users/..., file operations are significantly faster.

💡 Install the VS Code Remote - WSL extension. It makes working inside WSL feel completely native and comfortable.

💡 Use Windows Terminal. It's clean, fast, and supports multiple tabs including WSL sessions alongside PowerShell and CMD.

💡 Learn basic Bash. Even a small amount of Bash knowledge unlocks a lot of productivity inside WSL.

💡 Do: Run your dev servers, scripts, and build tools inside WSL for better compatibility.

🚫 Don't: Edit files stored in WSL using Windows Explorer directly. Use a proper editor with WSL integration to avoid permission issues.

🚫 Don't: Install WSL 1 unless you have a very specific reason. WSL 2 is almost always the better option.

Common Mistakes People Make With WSL

1. Storing project files on the Windows side

Many beginners put their projects in C:\Users\... and then access them from WSL via /mnt/c/.... This works, but it's slow. The cross-filesystem access between Windows and Linux has overhead.

Fix: Move your projects into the Linux file system (/home/username/) for much better performance.

2. Forgetting to set WSL 2 as default

After installing WSL, some people skip setting the default version to WSL 2 and end up running WSL 1 without realizing it.

Fix: Run this command once after installation:

wsl --set-default-version 2

3. Running GUI-heavy workflows without WSLg

Before WSLg (the GUI support layer), Linux GUI apps didn't work inside WSL. Some people still expect this limitation and miss out.

Fix: WSL 2 on recent versions of Windows 11 supports GUI Linux apps natively via WSLg. Just make sure your Windows is up to date.

4. Not using Windows Terminal

Opening WSL through the old Command Prompt window is not a great experience. Some users stick with it and wonder why things feel clunky.

Fix: Install Windows Terminal from the Microsoft Store. It is free, fast, and makes the whole experience far more enjoyable.

5. Treating WSL like a toy

Some people install WSL, run a few commands, and then forget about it. They miss the real value.

Fix: Actually build something with it. Run a server, set up a project, use Docker. Once you feel the difference in your actual workflow, you won't go back.

Conclusion

WSL is one of the best tools a Windows developer can have in their setup today. It closes the gap between Windows and Linux development without making you choose between them.

You get Linux tools, Linux compatibility, and Linux performance — right inside your Windows machine. No dual boot. No heavy VM. No excuses.

Whether you're a student learning Linux basics, a frontend developer following tutorials, or a backend engineer running servers locally, WSL makes your workflow smoother, faster, and a lot less frustrating.

If you haven't tried it yet, give it a shot. You might be surprised how quickly it becomes part of your daily routine. 🚀

Want more developer tips and tools explained clearly?
Visit hamidrazadev.com for more practical blog posts on frontend development, developer productivity, and web tools.

If this helped you, share it with a fellow developer who's still fighting Windows terminal issues. 😊

VS Code 1.115: The Update That Makes Your Dev Workflow Feel Like Magic 🚀

Muhammad Hamid Raza — Wed, 08 Apr 2026 13:12:56 +0000

Ever updated VS Code, glanced at the release notes, and thought "okay that's cool" — but then kept coding without really digging in? Same. Most of us miss genuinely useful features because the changelog can feel like a wall of text.

So let's fix that.

VS Code 1.115 dropped on April 3, 2026, and this one has some really solid improvements — especially if you're working with AI agents, terminals, or remote machines. Whether you're a solo dev or part of a team, there's something in here worth knowing about.

Let's break it all down in plain English. 👀

What Is VS Code 1.115?

VS Code releases updates in rolling cycles, and version 1.115 covers changes made between March 31 and April 2, 2026. These aren't massive rewrites — they're focused, practical improvements that smooth out real developer pain points.

This release touches four main areas:

Terminal improvements
Agent and chat session upgrades
Remote SSH support
UI and browser polish

Why This Update Matters

If you're using VS Code's built-in AI agent features, background terminals, or SSH remotes, this update directly improves how you work. The team at Microsoft is clearly doubling down on making AI-assisted development feel less clunky and more natural.

Even if you're not deep into agents yet, the terminal paste fix alone is worth noting. How many times have you needed to paste an image into a terminal and had to find a workaround? No more.

What's New in VS Code 1.115

Let's go through each update, grouped by day.

🗓️ April 2, 2026

Test coverage in the minimap

You can now enable test coverage indicators directly in the minimap. This is a subtle but useful addition for anyone doing TDD or trying to get a quick visual sense of how well their codebase is covered — without needing to open a separate panel.

Paste files into the terminal

You can now paste files — including images — into the integrated terminal using Ctrl+V, drag-and-drop, or right-click paste. This is one of those small things that makes a big difference when you're trying to move fast.

Background terminal improvements for agents

This one is big for AI agent workflows. Background terminals now automatically notify the agent when a command finishes, including the exit code and output. Even better — if a background terminal is waiting for user input, VS Code detects that and surfaces it to you.

Before this, agents could kick off a terminal command and then just... not know what happened. Now there's a proper feedback loop.

Pinch-to-zoom in the integrated browser (Mac)

Mac users can now use pinch-to-zoom gestures inside the integrated browser. A small quality-of-life upgrade, but it brings the built-in browser experience closer to a real browser.

code serve-web CLI updates

The code serve-web command now supports three new options:

--disable-telemetry
--default-folder
--default-workspace

Useful for teams running VS Code in a web/server context who want more control over the default experience.

🗓️ April 1, 2026

Copilot session entitlements and usage info

The Copilot status bar now shows entitlement and usage information inside Sessions. If you've ever wondered how much of your Copilot quota you've used mid-session, this gives you visibility without leaving your editor.

SSH remote support with automatic CLI setup

This is a genuinely useful addition. VS Code can now connect to remote machines over SSH and automatically install the CLI and start it in agent host mode. Previously, you'd need to set things up manually on the remote side. Now it handles it for you.

For anyone doing remote development — whether on a server, a cloud VM, or a colleague's machine — this removes a real friction point.

File edit tracking and restoration in agent sessions

Agents can now track and restore file edits made during a session. This means you get proper diffs, undo/redo, and state restoration for any changes an agent made.

This is important. AI-assisted editing is only as trustworthy as your ability to review and reverse it. Now you have the tools to do both.

🗓️ March 31, 2026

Chat can track and link open browser tabs

Chat sessions can now track browser tabs that were opened or interacted with during a session. Agents can reference those open pages directly. If you asked an agent to open docs and then want it to pull info from them, this makes that flow work properly.

send_to_terminal tool for agents

A new send_to_terminal tool lets agents send commands to background terminals — with user confirmation. This fixes a known issue where run_in_terminal with a timeout would push terminals to the background and make them read-only. Now that scenario is handled cleanly.

Rename agent sessions from the client side

You can now rename agent sessions directly from the client, thanks to a new rename capability in the Agent Host Protocol. Helpful when you're juggling multiple sessions and need to stay organized.

Favicons in Go to File quick pick

Open web pages now display their favicons in the Go to File quick pick list. A small visual improvement that makes it easier to identify browser tabs at a glance.

Comparison: Before vs. After — Agent Terminal Workflow

Scenario	Before 1.115	After 1.115
Agent runs background command	No notification when done	Agent gets exit code + output
Background terminal needs input	Silently blocked	Detected and surfaced to user
Agent sends command to terminal	`run_in_terminal` timeout issues	Clean `send_to_terminal` with confirmation
SSH remote setup	Manual CLI install required	Auto-installs CLI + starts agent host

If you work with agents regularly, this table basically summarizes why 1.115 is a meaningful release.

Tips for Getting the Most Out of VS Code 1.115

✅ Do:

Enable test coverage in the minimap if you're writing tests — it's a fast visual cue
Try the SSH auto-install feature on your next remote dev session instead of setting things up manually
Review agent session diffs before accepting them — the new restoration feature makes this easier than ever
Rename your agent sessions so you can find them later

❌ Don't:

Ignore background terminal notifications — they're telling you something important
Skip reviewing file edits made by agents just because undo is now available
Forget to check your Copilot usage in the Sessions panel if you're on a limited plan

Common Mistakes People Make After a VS Code Update

Skipping the release notes entirely

Most developers install the update and move on. The result? They miss features that could save them hours. You don't need to read everything — but skimming the highlights takes three minutes.

Not testing new agent features with real workflows

It's easy to read about a feature and think "cool" without actually using it. The background terminal improvements in 1.115 are genuinely useful — but you'll only feel that benefit if you try them in an actual agent session.

Assuming remote SSH setup is still manual

Habits are hard to break. If you've been setting up VS Code CLI manually on every remote machine, you might keep doing it out of muscle memory. The auto-install feature is now available — use it.

Overlooking small UI changes

The favicon display in Go to File and the minimap coverage indicators seem minor. But they add up. A cleaner visual workspace means fewer context switches and less cognitive load over a full workday.

Wrapping Up

VS Code 1.115 is a focused, practical update. It doesn't reinvent the editor — it makes the things you already do smoother, faster, and more reliable.

The biggest wins here are for developers working with AI agents and remote machines. The background terminal improvements, file edit tracking, and SSH auto-setup are all genuinely useful additions that remove real friction from real workflows.

If you haven't updated yet, do it. And actually read through the release notes — even just once. You'll find at least one feature that makes you think "wait, that was always the problem I had." 💡

For more practical dev content, check out hamidrazadev.com — new posts every week on tools, tips, and web development.

If this post helped you, share it with a developer friend who might be sleeping on these updates. Drop a comment if you found a feature in 1.115 that I didn't cover! 😊

Intersection Observer in JavaScript: Detect When Elements Enter the Screen (Without Breaking a Sweat)

Muhammad Hamid Raza — Tue, 07 Apr 2026 13:14:50 +0000

Ever built a webpage and thought, "Wouldn't it be cool if this animation only triggered when the user actually scrolls to it?" Or maybe you've seen lazy-loaded images on big websites and wondered how they know exactly when to load? 🤔

That magic has a name: the Intersection Observer API.

If you've ever tried to detect element visibility using scroll events and getBoundingClientRect(), you already know the pain. It works — until your page starts lagging because the browser is calculating positions on every single scroll tick. Not fun.

Intersection Observer was built to solve exactly that problem. It's clean, efficient, and honestly pretty satisfying to use once it clicks. Let's break it down.

What Is the Intersection Observer API?

The Intersection Observer API is a built-in JavaScript browser API that lets you watch when an element enters or exits the viewport (or any scrollable container) — without using scroll events.

Think of it like a security guard standing at the entrance of a room. Instead of you constantly running to the door to check if someone arrived, the guard simply calls you the moment someone walks in. You don't have to do anything. You just wait for the call.

In code terms: you tell the browser "hey, watch this element for me", and the browser notifies you the moment it becomes visible or hidden. No polling. No performance headaches. Just a clean callback.

Why This Matters for Developers

Before Intersection Observer existed, developers used scroll event listeners combined with getBoundingClientRect() to track element positions. It worked, but it had real problems:

Performance issues — scroll events fire extremely fast, dozens of times per second. Running calculations inside them tanks performance on complex pages.
Forced reflows — calling getBoundingClientRect() forces the browser to recalculate layout, which is expensive.
Messy code — handling debouncing, cleanup, and edge cases made the code complicated fast.

Intersection Observer solves all of this. The browser handles the detection natively and efficiently, and your callback only runs when something actually changes. It's the right tool for the job.

Benefits with Real-Life Examples

Lazy loading images — Instead of loading all 80 product images on a page at once, you load them only when they're about to appear on screen. Faster initial load, less wasted bandwidth. ⚡
Scroll-triggered animations — Cards, text, or UI sections animate in only when the user scrolls to them. Feels polished, costs almost nothing extra.
Infinite scroll — When the last list item enters the viewport, trigger the next page fetch. This is exactly how Twitter and Instagram feeds work.
Sticky headers and nav highlights — Track which section is currently visible and highlight the matching navigation link automatically.
Analytics and ad visibility tracking — Know whether a user actually saw an ad or section, not just whether the page loaded.

Each of these used to require messy scroll handlers. Now they're clean, readable, and fast.

How to Use It: Basic Syntax

Here's the simplest form of Intersection Observer:

const observer = new IntersectionObserver((entries) => {
  entries.forEach((entry) => {
    if (entry.isIntersecting) {
      console.log('Element is visible!', entry.target);
    }
  });
});

const target = document.querySelector('.my-element');
observer.observe(target);

That's it for the basics. Let's understand what each part does.

The Callback

The callback receives an array of entries. Each entry represents an observed element and includes useful properties:

entry.isIntersecting — true if the element is currently visible in the viewport.
entry.target — the actual DOM element being observed.
entry.intersectionRatio — how much of the element is visible, from 0 to 1.
entry.boundingClientRect — the element's size and position.

The Options Object

You can pass an options object as the second argument to control behavior:

const options = {
  root: null,         // null = viewport; or pass a scrollable element
  rootMargin: '0px',  // expand or shrink the detection area
  threshold: 0.5      // trigger when 50% of the element is visible
};

const observer = new IntersectionObserver(callback, options);

root — The container to check against. null means the browser viewport.
rootMargin — Like CSS margin, it expands or shrinks the detection zone. "100px" would trigger 100px before the element actually enters the viewport — great for preloading.
threshold — A value (or array of values) between 0 and 1 defining when the callback fires. 0 = any pixel visible, 1 = fully visible.

Practical Example: Scroll-Triggered Animation

Here's a real, working example you can drop into any project:

HTML:

<div class="card fade-in">Hello, I animate in! 👋</div>
<div class="card fade-in">So do I!</div>
<div class="card fade-in">Me too!</div>

CSS:

.fade-in {
  opacity: 0;
  transform: translateY(30px);
  transition: opacity 0.6s ease, transform 0.6s ease;
}

.fade-in.visible {
  opacity: 1;
  transform: translateY(0);
}

JavaScript:

const observer = new IntersectionObserver((entries) => {
  entries.forEach((entry) => {
    if (entry.isIntersecting) {
      entry.target.classList.add('visible');
      observer.unobserve(entry.target); // stop watching after animation
    }
  });
}, { threshold: 0.1 });

document.querySelectorAll('.fade-in').forEach((el) => observer.observe(el));

The observer.unobserve() call on line 5 is key — once the animation fires, there's no reason to keep watching that element. This keeps things clean and memory-efficient.

Comparison: Scroll Event vs Intersection Observer

Feature	Scroll Event + getBoundingClientRect	Intersection Observer
Performance	Poor on complex pages	Excellent, native browser optimization
Ease of use	Complex, lots of boilerplate	Clean and minimal
Debouncing needed	Yes	No
Viewport detection	Manual calculation	Built-in
Multiple elements	Gets messy fast	Observe as many as you need
Browser support	Universal	All modern browsers ✅

The scroll event approach isn't wrong — but for visibility tracking, Intersection Observer is almost always the better choice.

Best Tips / Do's & Don'ts

✅ Do:

Always call observer.unobserve(entry.target) after a one-time action (like triggering an animation) to free up resources.
Use rootMargin for preloading — trigger things slightly before they enter the viewport for a smoother user experience.
Pass an array of thresholds like [0, 0.25, 0.5, 0.75, 1] if you need to track how much of an element is visible at different stages.
Store your observer in a variable so you can call observer.disconnect() when the component unmounts (especially important in React).

❌ Don't:

Don't use it for detecting exact pixel positions in real time — that's still scroll events territory.
Don't forget to call observer.disconnect() when you're done. Leaving observers running indefinitely wastes memory.
Don't set threshold: 1 for large elements that might never be 100% visible on small screens. Your callback will never fire.
Don't create a new observer instance for each element. One observer can watch many elements at once.

Common Mistakes People Make

1. Forgetting to unobserve or disconnect

This is the most common mistake. If you observe 50 elements on a page and never stop watching them, you're holding references and running callbacks unnecessarily. Always clean up.

2. Using threshold: 1 on tall elements

If your element is taller than the viewport, it will never be 100% visible — so a threshold of 1 means your callback never fires. Use 0.1 or 0.2 for tall sections.

3. Creating one observer per element

// ❌ Wrong way
elements.forEach((el) => {
  const obs = new IntersectionObserver(callback);
  obs.observe(el);
});

// ✅ Right way
const observer = new IntersectionObserver(callback);
elements.forEach((el) => observer.observe(el));

One observer, many targets. Cleaner and more efficient.

4. Not checking isIntersecting inside the callback

The callback fires both when elements enter and exit the viewport. If you don't check entry.isIntersecting, your logic runs in both cases — which often causes bugs.

5. Relying on it for critical layout logic without a fallback

Modern browser support is excellent, but if you're building something that needs to work in very old environments, check caniuse.com and consider a polyfill.

Conclusion

The Intersection Observer API is one of those browser features that once you learn, you start seeing use cases everywhere. Lazy loading, animations, infinite scroll, analytics — it handles them all cleanly and efficiently.

It replaces a whole category of scroll-event spaghetti with just a few lines of readable code. Your users get a smoother experience, your codebase stays clean, and your browser stops crying. Everyone wins. 🚀

The next time you need to detect element visibility on a page, reach for Intersection Observer first. It was literally built for this.

Want more practical JavaScript and frontend tips like this? Head over to hamidrazadev.com for more posts, tutorials, and guides. If this helped you, share it with a fellow developer — they'll thank you for it. 😊

Google Stitch: The AI Design Tool Developers Need to Know About in 2026

Muhammad Hamid Raza — Mon, 06 Apr 2026 12:22:39 +0000

You have an app idea. You know what it should do. You even know roughly what it should look like.

But then you open a blank Figma file and... nothing. The blank canvas paralysis hits. You spend two hours pushing boxes around, and the result still looks like a college assignment from 2009.

Sound familiar? 😅

That is exactly the problem Google Stitch was built to fix. It is a free AI-powered UI design tool from Google Labs that lets you describe your interface in plain English—and it generates a polished, production-ready design for you in seconds, complete with real frontend code.

Whether you are a developer who struggles with design, a designer who wants to move faster, or a founder who needs to prototype an idea without hiring an agency—Stitch might just become your new favorite tool.

What Is Google Stitch?

Google Stitch is an AI-powered UI design tool developed by Google Labs that transforms text prompts or uploaded wireframes into mobile and web user interface designs.

It leverages the multimodal power of Gemini 3 Flash and Gemini 3 Pro to create a fluid, integrated workflow between design and development.

Three Tools in One:

Design Generator: Describe your UI and it creates it visually.
Code Exporter: Get clean HTML, CSS, or React (TypeScript) code instantly.
Figma Bridge: Paste your design directly into Figma for further polish.

The best part? It’s fully web-based. All you need is a Google account—no installations or environment setup required.

Why Google Stitch Matters for Developers

Most developers are not designers. And that is completely fine—except when you need to ship a product fast and there is no designer on the team.

Stitch allows anyone to turn natural language into high-fidelity UI designs. For a solo dev, this means going from "I need a dashboard" to a functional layout in under five minutes.

The Impact:

Zero to Hero: No Figma expertise? No problem.
Instant Handoff: The "design" is already code.
Massive Speed: Cuts design time from days to minutes.

Key Features & Real-Life Examples

1. Turn Plain English into Full UI

Describe your application including details like color palettes or user experience.

Prompt: "A dark-themed mobile dashboard for a crypto tracking app with a navbar, portfolio card, and price chart using #0a0a0a and #22d3ee accents."

2. Upload Sketches and Wireframes

Have a whiteboard sketch or a rough screenshot? Upload it. Stitch processes the image to produce a corresponding digital UI, bridging the gap between a napkin sketch and a functional design.

3. Production-Ready Code

Stitch doesn't just "draw" boxes; it writes them. You can export:

Tailwind CSS + React
Standard HTML/CSS
TypeScript components

4. The "Wildcard" Variant Engine

Design is iterative. Use Stitch to generate multiple variants of a single screen instantly. Experiment with layouts, components, and styles without manual dragging and dropping.

Google Stitch vs. Traditional Workflow

Feature	Google Stitch (AI)	Traditional Figma Workflow
Design Speed	Seconds (Prompt-based)	Hours (Manual placement)
Skill Floor	Low (English proficiency)	High (Design principles/Figma)
Dev Handoff	Built-in (Code ready)	Manual (Inspection/Export)
Cost	Free (Labs)	Paid (Professional tiers)
Best For	Prototyping, Solo Devs	Full Design Systems, Large Teams

How to Use Google Stitch: Step-by-Step

Sign In: Visit stitch.withgoogle.com and log in with your Google account.
Pick Your Mode: * Standard (Gemini 3 Flash): Fast, lightweight exploration.
- Experimental (Gemini 3 Pro): High-fidelity, detailed complex designs.
Write a Clear Prompt: Include platform (Web/Mobile), core components (Navbar/Cards), and visual style (Minimal/Dark Mode).
Refine & Iterate: Use follow-up prompts to change one or two things at a time.
Export: Choose between "Paste to Figma" or "Download Code."

Best Tips for Success 💡

Be Specific: Vague prompts give vague results. Use hex codes and component names.
The One-Change Rule: Don't ask for a complete overhaul in one prompt. Change the navbar first, then the font, then the colors.
Use DESIGN.md: Export your design system as a .md file to keep branding consistent across multiple projects.
Test Standalone: Always run the exported code in a local browser before integrating it into a complex app.

Conclusion

Google Stitch genuinely changes how fast you can go from idea to interface. It’s a game-changer for developers who want to design without becoming a full-time designer.

It is free, browser-based, and integrates with the tools you already use. There is no reason not to give it a spin.

Try it today: stitch.withgoogle.com

If this guide was helpful, share it with a dev friend! For more practical tools and frontend guides, head over to hamidrazadev.com.

CSS Flexbox Explained: The Layout Superpower Every Developer Needs

Muhammad Hamid Raza — Sun, 05 Apr 2026 11:48:13 +0000

If you've ever tried to center a div and ended up Googling it for the fifth time this week — welcome, you're in the right place. 😄

CSS layouts used to be a bit of a nightmare. Floats, clearfixes, position: absolute hacks — developers had to jump through all sorts of hoops just to align a few boxes. Then Flexbox came along and changed everything.

Flexbox, short for Flexible Box Layout, is one of the most useful tools in modern CSS. Once you actually understand it — not just copy-paste it — layouts start feeling almost fun. So let's break it down from scratch and make it click.

What Is Flexbox?

Flexbox is a CSS layout model that helps you arrange elements inside a container — horizontally, vertically, or both — with much less effort than older methods.

Think of it like a shelf organizer. You have a shelf (the flex container), and you're placing books on it (the flex items). Flexbox lets you decide how those books are spaced out, aligned, and sized — all with a few CSS properties.

You activate Flexbox with one line:

.container {
  display: flex;
}

That's it. The moment you write that, every direct child of .container becomes a flex item, and Flexbox starts managing them.

Why Flexbox Matters

Before Flexbox, centering something vertically in CSS was genuinely painful. Developers used margins, transforms, and table-cell tricks just to get a div in the middle of the page.

Flexbox solved that. It also solved:

Making equal-height columns without JavaScript
Building responsive navigation bars
Distributing space evenly between elements
Reordering elements without touching the HTML

Today, Flexbox is supported in all modern browsers. It's a core skill for frontend developers, and you'll use it in almost every project you build.

Benefits with Real-Life Examples

1. Centering made easy ✅

Centering a div — both horizontally and vertically — used to be a meme in the dev community. With Flexbox:

.container {
  display: flex;
  justify-content: center;
  align-items: center;
}

That's genuinely all you need. Three lines and you're done.

2. Responsive navbars without pain

Building a navigation bar that spreads links across the full width? Flexbox handles it naturally with justify-content: space-between.

3. Equal-height cards automatically

In a blog or product listing, cards in the same row have equal height by default when using Flexbox — no extra CSS or JavaScript needed.

4. Control direction easily

Want items stacked vertically? Just change one property:

flex-direction: column;

This is incredibly useful for mobile layouts.

5. Reorder items without changing HTML

The order property lets you visually reorder flex items without touching the markup. Great for responsive design where you want a different layout on mobile vs desktop.

The Core Flexbox Properties You Need to Know

On the Container (Parent)

display: flex
Activates Flexbox on the container.

flex-direction
Controls which direction items flow.

row (default) — left to right
column — top to bottom
row-reverse and column-reverse — reversed directions

justify-content
Aligns items along the main axis (horizontal by default).

flex-start — all items pushed to the start
flex-end — all items pushed to the end
center — items centered
space-between — equal space between items, none on edges
space-around — equal space around each item
space-evenly — truly equal space everywhere

align-items
Aligns items along the cross axis (vertical by default).

flex-start, flex-end, center — same idea, but vertical
stretch (default) — items stretch to fill the container height
baseline — items align by their text baseline

flex-wrap
By default, flex items stay in one row even if they overflow. flex-wrap: wrap allows them to jump to the next line.

gap
Adds space between flex items. Much cleaner than using margins on each item.

.container {
  display: flex;
  gap: 16px;
}

On the Items (Children)

flex-grow
Defines how much a flex item should grow relative to others if there's extra space. A value of 1 means it will grow to fill available space.

flex-shrink
Controls how much an item shrinks when there's not enough space. Default is 1.

flex-basis
Sets the initial size of a flex item before growing or shrinking. Think of it as the "starting width."

flex (shorthand)
The shorthand for flex-grow, flex-shrink, and flex-basis combined.

.item {
  flex: 1; /* grow: 1, shrink: 1, basis: 0% */
}

Using flex: 1 on all items makes them equal width — super useful for grid-like layouts.

align-self
Overrides align-items for a single item. Want one card to align differently from the rest? This is your property.

order
Changes the visual order of a flex item. Default is 0. Lower values appear first.

Main Axis vs Cross Axis — The Key Concept

This is where many people get confused, and it's worth taking a moment here.

Flexbox has two axes:

The main axis runs in the direction of flex-direction
The cross axis runs perpendicular to it

If flex-direction is row (default), the main axis is horizontal and the cross axis is vertical.

justify-content always controls the main axis.
align-items always controls the cross axis.

Once you internalize this, the whole system makes sense. It's not about "horizontal" or "vertical" in absolute terms — it's about main and cross.

Flexbox vs CSS Grid — Which Should You Use?

This is a common question and the answer is: they complement each other, not compete.

Feature	Flexbox	CSS Grid
Best for	One-dimensional layouts (row OR column)	Two-dimensional layouts (rows AND columns)
Use case	Navbars, card rows, centering	Full page layouts, complex grids
Browser support	Excellent	Excellent
Complexity	Simpler to start with	More powerful for complex layouts

A practical rule: use Flexbox when you're working in one direction. Use CSS Grid when you need rows and columns at the same time. Often you'll use both on the same page.

Best Tips for Using Flexbox

✅ Use gap instead of margins between items
It's cleaner, easier to manage, and doesn't create edge-case spacing issues.

✅ Remember that justify-content and align-items depend on flex-direction
When you switch to flex-direction: column, the axes flip. Many beginners forget this.

✅ Use flex: 1 for equal-width items
Adding flex: 1 to all children in a flex container makes them share space equally — a quick way to create column layouts.

✅ Use flex-wrap: wrap for responsive layouts
Without it, items will squish or overflow on small screens. Adding wrap lets them flow naturally.

✅ Use browser DevTools to debug
Chrome and Firefox both have Flexbox inspector tools. They visualize your layout in real time and save a lot of guessing.

Common Mistakes People Make

❌ Applying flex properties to the wrong element

justify-content and align-items go on the container, not the items. Beginners often add them to the wrong element and wonder why nothing changes.

❌ Forgetting that axes flip with flex-direction: column

When you switch to column direction, justify-content controls vertical alignment and align-items controls horizontal. This is the most common source of confusion.

❌ Using width: 100% on flex items unnecessarily

When you set flex: 1 or use flex-grow, adding width: 100% can actually break the layout. Trust Flexbox to handle sizing.

❌ Overusing Flexbox for two-dimensional layouts

If you're fighting Flexbox to build a grid layout, CSS Grid is probably the better tool. Don't force a one-dimensional system to do two-dimensional work.

❌ Not using flex-wrap on responsive containers

A common issue — items overflow on mobile because flex-wrap wasn't set. Always consider wrapping when building for different screen sizes.

Quick Reference Cheat Sheet

/* Container */
.container {
  display: flex;
  flex-direction: row | column | row-reverse | column-reverse;
  justify-content: flex-start | flex-end | center | space-between | space-around | space-evenly;
  align-items: flex-start | flex-end | center | stretch | baseline;
  flex-wrap: nowrap | wrap | wrap-reverse;
  gap: 16px;
}

/* Items */
.item {
  flex: 1;              /* grow, shrink, basis shorthand */
  flex-grow: 1;
  flex-shrink: 1;
  flex-basis: 200px;
  align-self: center;
  order: 2;
}

Conclusion

Flexbox is one of those tools that feels tricky for the first hour and then becomes second nature forever. The moment it clicks — especially the main axis vs cross axis concept — you'll start seeing layouts differently.

Once you understand that display: flex on the parent, justify-content for the main axis, and align-items for the cross axis are the three core pillars, the rest falls into place naturally. Everything else is just extra control on top of that foundation.

Start small. Build a centered card. Then try a navbar. Then a card row that wraps on mobile. Each one teaches you something new.

And when you're ready to go deeper into CSS, React, Next.js, and modern frontend development, head over to hamidrazadev.com — there's a lot more waiting for you there. 🚀

If this helped you finally understand Flexbox, share it with a dev friend who's still cursing at their layout. They'll thank you later. 😊

Kali Linux 2026.1 Is Here — And It Brought a Time Machine 🚀

Muhammad Hamid Raza — Sat, 04 Apr 2026 12:27:34 +0000

Have you ever wished your terminal could look cooler and feel nostalgic at the same time? Kali Linux just made that happen.

Kali Linux 2026.1 has officially dropped, and this release is more exciting than your average quarterly update. We are talking a full visual overhaul, a nostalgic surprise for longtime fans, brand new tools, kernel upgrades, and some serious NetHunter improvements.

Whether you are a penetration tester, a cybersecurity student, or just someone who loves watching their Kali boot screen with a coffee in hand — this release has something for you. So let's break it all down. 👀

What Is Kali Linux 2026.1?

If you are new here: Kali Linux is a Debian-based Linux distribution built specifically for penetration testing, ethical hacking, digital forensics, and security research. It is maintained by OffSec and is one of the most widely used platforms in the cybersecurity world.

Every year, the Kali team drops a xx.1 release with a fresh visual theme, new tools, and improvements across the board. The 2026.1 release follows that same tradition — but this time, it comes with a very special birthday gift.

Kali Linux just turned 13. And BackTrack Linux, Kali's legendary predecessor, just turned 20.

That is a lot of anniversaries to celebrate. And the team absolutely delivered.

Why Kali Linux 2026.1 Matters

You might be thinking: "It is just a theme update and a few new tools. Why should I care?"

Fair question. But this release is more than cosmetic.

Here is why it matters for developers and security professionals:

The kernel has been bumped to 6.18, bringing better hardware support and performance improvements.
8 new tools have been added to the repositories — covering areas from XSS scanning to post-exploitation frameworks.
NetHunter improvements mean mobile pentesting just got more capable on more devices.
The BackTrack Mode is not just nostalgia — it shows how far the ecosystem has come and gives veteran users a reason to smile.
183 package updates and 25 new packages keep the toolset sharp and current.

If you are actively using Kali for security work, these are meaningful improvements worth upgrading for.

Key Features and What They Actually Do

🎨 2026 Theme Refresh

Every .1 release comes with a theme refresh, and 2026 is no exception.

The new theme touches everything: the boot animation, the GRUB menu, the graphical installer, the login screen, and the desktop wallpaper. Kali Purple also gets a matching refresh for those who prefer the purple variant.

One small but appreciated fix? The boot animation used to get stuck at the tail on live images. That is now fixed, and it loops smoothly if the boot process takes longer than expected. Not a major thing — but anyone who has stared at a frozen boot animation knows the relief.

🕹️ BackTrack Mode for Kali-Undercover

This is the most interesting addition in this release.

Kali-Undercover is an existing feature that makes your Kali desktop look like a regular Windows setup — great for working in public without drawing attention.

Now, Kali-Undercover has a new BackTrack Mode that transforms the desktop to look like BackTrack 5 — complete with the original wallpaper, colors, and window theme.

For those who do not know: BackTrack Linux was the go-to hacking distribution before Kali took over in 2013. It was legendary. Running BackTrack Mode in 2026 is like putting on a retro jersey — functional, stylish, and deeply nostalgic.

To activate it, you run:

kali-undercover --backtrack

Run it again to switch back. Simple and clean.

🛠️ 8 New Tools Added

Here is a quick look at what is new in the repositories:

AdaptixC2 — An extensible post-exploitation and adversarial emulation framework
Atomic-Operator — Runs Atomic Red Team tests across multiple operating systems
Fluxion — A security auditing and social-engineering research tool
GEF — A modern GDB experience with advanced debugging capabilities
MetasploitMCP — An MCP server for Metasploit
SSTImap — Automatic SSTI detection with an interactive interface
WPProbe — Fast WordPress plugin enumeration
XSStrike — An advanced XSS scanner

Whether you are testing web apps, running red team exercises, or debugging exploits, these additions cover a wide range of real security scenarios.

📱 Kali NetHunter Updates

Mobile pentesting is alive and well. This release brings:

Bug fixes including the WPS scan issue, HID permission check, and the back button problem
A new kernel for Redmi Note 8 (Ginkgo) supporting Android 16
A libnexmon patch for Samsung S10 series that finally gets reaver, bully, and kismet working properly
The first working QCACLD v3.0 injection patch — which could potentially unlock wireless injection on a huge number of Qualcomm-based phones

That last one is significant. If you have ever tried to do wireless testing on a Qualcomm phone and hit a wall, this is the patch you have been waiting for.

Pros and Cons of Upgrading to Kali 2026.1

✅ Pros	⚠️ Things to Know
Fresh theme and UI across the board	SDR tools (gr-air-modes, gqrx-sdr) are known to be broken in this release
Kernel 6.18 for better hardware support	The fix is expected in the next release
8 new tools added	Some packages removed (9 total)
BackTrack Mode for nostalgia fans	—
Significant NetHunter improvements	—
183 package updates	—

The main known issue is with the kali-tools-sdr metapackage. If you work with Software Defined Radio tools, it might be worth waiting for the next release or using workarounds in the meantime. The team has acknowledged it and expects a fix soon.

Best Tips for This Release

✅ Do's:

Update cleanly. If you are on an existing install, use the full upgrade command:

  sudo apt update && sudo apt -y full-upgrade

Copy the skel config after upgrading:

  cp -vrbi /etc/skel/. ~/

Check your kernel version after upgrading to confirm you are on 6.18.
Try BackTrack Mode — even if just for the experience. It is a fun piece of cybersecurity history.
Explore the new tools — especially XSStrike and SSTImap if you do web security testing.

❌ Don'ts:

Don't use the SDR metapackage if you depend on gqrx-sdr or gr-air-modes right now. Wait for the fix.
Don't report bugs on social media. The team specifically asks that bug reports go through the official bug tracker, not Twitter or Instagram.
Don't skip the skel copy step — it updates your config files to match the new theme properly.

Common Mistakes People Make When Updating Kali

1. Skipping the full-upgrade in favor of just upgrade

apt upgrade and apt full-upgrade are different. On Kali, you almost always want full-upgrade because it handles package replacements and removals. Skipping it can leave your system in a mixed state.

2. Not checking for broken packages after upgrading

After any major upgrade, running apt --fix-broken install is a good habit. It catches issues before they turn into bigger problems.

3. Forgetting to copy the skel files

This step updates your terminal profile, desktop config, and theme settings. Skipping it means your desktop might not reflect the new 2026 theme properly.

4. Expecting SDR tools to work in this release

The team was upfront about the GNU Radio ecosystem issue. If you depend on those tools, stay on 2025.4 for now or use a workaround. Patience here saves a lot of frustration.

5. Using weekly builds as if they are stable releases

Weekly builds are automated. They are great for getting the latest packages fast, but they skip the QA process that standard releases go through. Use them knowing that.

Conclusion

Kali Linux 2026.1 is a solid release that mixes polish with practicality. The 2026 theme refresh keeps the interface modern. The BackTrack Mode is a well-deserved nod to where it all started. The new tools expand the already impressive Kali arsenal. And the NetHunter updates push mobile pentesting forward in meaningful ways.

Yes, there is a known SDR issue. But the team was honest about it, and a fix is already expected in the next release. That kind of transparency is worth appreciating.

If you are a Kali user, update when you are ready. If you are new to the platform, this is a great time to start exploring.

Happy hacking. Stay ethical. And as always — learn something new today. 💡

👉 Want more content like this? Check out my developer blog at hamidrazadev.com for practical articles on tools, frameworks, and everything developers love to talk about. Share this post with a fellow security enthusiast if it helped you!