Category: Tools & Setup

I needed a place to store code snippets, email templates, and frequently pasted text blocks. Everything I found was either a full IDE extension, a note-taking app in disguise, or yet another Electron app eating 200MB of RAM. So I built TypeFast — a snippet manager that runs in a browser tab.

The Snippet Graveyard Problem

Every developer has one. A folder called snippets or useful-stuff sitting somewhere in their home directory. A Notion page titled “Code Templates” that hasn’t been updated since 2023. Three GitHub Gists they can’t find because they never gave them proper names. Slack messages to themselves that got buried under 400 notifications.

The common thread: the tool was never designed for quick retrieval. Notion is a document editor. Gists are for sharing, not searching. Slack is for messaging. Using them as snippet managers is like using a spreadsheet as a to-do list — it technically works, but the friction kills you.

What TypeFast Actually Does

TypeFast has exactly four features:

1. Add a snippet — give it a title, a category, paste the content
2. Find a snippet — type in the search bar, or filter by category tab
3. Copy a snippet — one click, it’s on your clipboard, a “✅ Copied!” confirmation appears
4. Edit or delete — because snippets evolve

That’s it. No folders, no tags cloud, no sharing, no collaboration, no AI suggestions. Just a fast, searchable list with a copy button.

The Technical Non-Architecture

TypeFast is a single HTML file. No React, no Vue, no build step. The entire application — HTML, CSS, and JavaScript — weighs about 10KB. It stores data in localStorage, which means:

• No server, no database, no API calls
• Data persists across browser sessions
• No account, no sync, no privacy concerns
• Works offline (it’s also a PWA)

The trade-off is obvious: your snippets live only in that browser, on that device. If you clear your browser data, they’re gone. For most people, this is fine — snippets aren’t precious documents. But if you want durability, export them (coming in a future update) or just keep the tab pinned.

How the App Architecture Works

Most web apps start with npx create-react-app and immediately inherit thousands of dependencies, a build pipeline, and a node_modules folder heavier than the app itself. TypeFast takes the opposite approach: vanilla JavaScript with zero dependencies, organized around an event-driven pattern that would look familiar to anyone who wrote web apps before the framework era.

The DOM manipulation strategy is intentionally boring. Instead of a virtual DOM or reactive bindings, TypeFast uses document.createElement() for building snippet cards and direct property assignment for updates. When the snippet list changes, the app clears the container and rebuilds it. For a list of a few hundred items, this is imperceptibly fast — the browser’s layout engine handles it in under a frame.

State management is a plain JavaScript object that gets serialized to localStorage on every mutation. Here’s the actual core data model:

// Core data model — everything TypeFast needs
const AppState = {
  snippets: [],
  categories: ['General'],
  activeCategory: 'All',
  searchQuery: ''
};

// Persist to localStorage on every mutation
function saveState() {
  localStorage.setItem('typefast_data', JSON.stringify({
    snippets: AppState.snippets,
    categories: AppState.categories
  }));
}

// Hydrate on startup
function loadState() {
  const saved = localStorage.getItem('typefast_data');
  if (saved) {
    const data = JSON.parse(saved);
    AppState.snippets = data.snippets || [];
    AppState.categories = data.categories || ['General'];
  }
}

That’s the entire state layer. No Redux store with actions and reducers. No Vuex modules. No React context providers wrapping five levels deep. A single object, two functions, and localStorage as the persistence layer. When something changes, call saveState(). When the page loads, call loadState(). The simplicity is the feature — there are zero state synchronization bugs because there’s only one source of truth.

Code Walkthrough: The Snippet Engine

The search and filter system is the heart of TypeFast. Every keystroke in the search bar triggers a filter pass across all snippets. Here’s the actual implementation:

function filterSnippets() {
  const query = AppState.searchQuery.toLowerCase();
  const category = AppState.activeCategory;

  return AppState.snippets.filter(snippet => {
    const matchesCategory = category === 'All' || snippet.category === category;
    const matchesSearch = !query ||
      snippet.title.toLowerCase().includes(query) ||
      snippet.content.toLowerCase().includes(query) ||
      snippet.category.toLowerCase().includes(query);
    return matchesCategory && matchesSearch;
  });
}

It searches across title, content, and category simultaneously. No fancy indexing, no search library — just Array.filter() and String.includes(). For collections under a few thousand snippets, this brute-force approach is faster than the overhead of maintaining a search index.

The more interesting piece is the template variable system. TypeFast lets you embed dynamic placeholders in your snippets that get expanded at copy time. Type {{date}} in a snippet and it becomes today’s date when you copy it:

// Template variables — type {{date}} and get today's date
const TEMPLATE_VARS = {
  '{{date}}': () => new Date().toISOString().split('T')[0],
  '{{time}}': () => new Date().toLocaleTimeString(),
  '{{timestamp}}': () => Date.now().toString(),
  '{{uuid}}': () => crypto.randomUUID(),
  '{{clipboard}}': async () => {
    try {
      return await navigator.clipboard.readText();
    } catch {
      return '{{clipboard}}'; // fallback if permission denied
    }
  }
};

async function expandTemplateVars(text) {
  let result = text;
  for (const [pattern, resolver] of Object.entries(TEMPLATE_VARS)) {
    if (result.includes(pattern)) {
      const value = await resolver();
      result = result.replaceAll(pattern, value);
    }
  }
  return result;
}

The {{clipboard}} variable is particularly useful: it reads the current clipboard content and injects it into the snippet. So you can create a template like git commit -m "{{clipboard}}", copy some text, then copy the snippet, and the clipboard content gets wrapped in the git command. The copy-to-clipboard function processes all template variables before writing to the clipboard, so the user always gets the fully expanded version.

The one-click copy includes visual feedback so you know something happened:

async function copySnippet(snippetId) {
  const snippet = AppState.snippets.find(s => s.id === snippetId);
  if (!snippet) return;

  const expanded = await expandTemplateVars(snippet.content);

  await navigator.clipboard.writeText(expanded);

  // Visual feedback
  const btn = document.querySelector(`[data-copy="${snippetId}"]`);
  const original = btn.textContent;
  btn.textContent = '✅ Copied!';
  btn.classList.add('copied');
  setTimeout(() => {
    btn.textContent = original;
    btn.classList.remove('copied');
  }, 1500);
}

The 1500ms timeout for the feedback animation is deliberate — long enough to register visually, short enough that it resets before you need to copy another snippet. The copied CSS class triggers a brief green highlight animation on the button. Small detail, but it’s the difference between “did that work?” and “done, next.”

Performance: TypeFast vs Electron Alternatives

The entire reason TypeFast exists is that snippet managers shouldn’t need Electron. Here’s how it compares against typical alternatives:

I tested this by loading 1,000 snippets into TypeFast and measuring search latency with performance.now(). The filter function runs in under 1ms because it’s just Array.filter() on a JavaScript array that’s already in memory. No database queries, no IPC calls, no virtual DOM diffing. The bottleneck isn’t the search — it’s the DOM rebuild, which still finishes in under 16ms (one frame at 60fps).

RAM usage is the most dramatic difference. An Electron app bundles an entire Chromium instance, which starts at about 80MB before your app code even loads. TypeFast shares the Chromium instance you already have open — your browser. The marginal cost of one more tab is roughly 15MB, and that includes the full snippet dataset.

The Build and Deploy Pipeline (There Isn’t One)

TypeFast has no build step. No webpack config, no Vite setup, no Babel transpilation. The source code is the production artifact. This is a deliberate choice, not a limitation — when your entire app is a single HTML file, build tooling adds complexity without adding value.

The app is served by nginx running on my homelab TrueNAS box. Here’s the full server config:

server {
    listen 443 ssl http2;
    server_name typefast.orthogonal.info;

    root /usr/share/nginx/typefast;
    index index.html;

    # Cache everything aggressively — it's one file
    location / {
        add_header Cache-Control "public, max-age=86400";
        try_files $uri $uri/ /index.html;
    }

    # Security headers
    add_header X-Content-Type-Options nosniff;
    add_header X-Frame-Options DENY;
    add_header Content-Security-Policy "default-src 'self' 'unsafe-inline'";
}

The entire deploy pipeline is one line:

scp index.html [email protected]:/mnt/data/nginx/typefast/

No CI/CD, no Docker build, no artifact registry. When your app is a single file, you don’t need infrastructure. The security headers in the nginx config are honestly overkill for a static HTML file, but old habits die hard when you spend your day job doing security engineering. The Content-Security-Policy header restricts the page to only loading resources from itself, which means even if someone injected a script tag via a snippet, it wouldn’t be able to phone home. Defense in depth, even for a 12KB app.

Use Cases I Didn’t Expect

• A support team member saves 15 canned responses, copies the right one in under 2 seconds
• A writer keeps character descriptions and plot points for quick reference
• A sysadmin stores SSH commands, config blocks, and one-liners
• A recruiter saves personalized outreach templates by role type

Try It

👉 typefast.orthogonal.info

It comes pre-loaded with two example snippets. Delete them, add your own, and see if it sticks. If you’re still using a text file for snippets in a week, I’ll be surprised.

Frequently Asked Questions

Every photo taken on a smartphone embeds invisible metadata — including GPS coordinates accurate to within a few meters. PixelStrip strips it all out before you share. Zero upload, zero tracking, zero excuses.

A Quick Experiment

Pick any photo from your camera roll. Right-click it on your computer, open Properties (Windows) or Get Info (Mac), and look for the GPS fields. If location services were on when you took the photo — and they almost certainly were — you’ll see latitude and longitude coordinates that pinpoint exactly where you were standing.

Now imagine you posted that photo on a forum, sold something with it on Craigslist, or sent it in a group chat that got forwarded around. Anyone who saves the image can extract those coordinates and drop them into Google Maps. They’ll see your home, your office, your kid’s school.

This isn’t theoretical. It’s happened to journalists, activists, and abuse victims. And it’s happening to you right now, every time you share an unstripped photo.

What’s Hiding in Your Photos

The EXIF (Exchangeable Image File Format) standard was designed in the 1990s for digital cameras. It stores useful technical data — aperture, shutter speed, focal length. But smartphones added fields that were never meant to be shared publicly:

• GPS coordinates — latitude, longitude, altitude, and sometimes direction
• Device fingerprint — phone make, model, OS version, unique camera serial number
• Timestamps — date and time of capture, modification history
• Thumbnail images — a smaller version of the original, sometimes containing content you cropped out
• Software chain — every app that touched the image

Social media platforms like Facebook, Instagram, and Twitter strip EXIF data on upload — but email, messaging apps, forums, file-sharing services, and most CMS platforms do not.

How PixelStrip Works

PixelStrip parses the JPEG binary structure directly in your browser using JavaScript. It identifies EXIF markers (APP1 segments), IFD entries, and GPS sub-IFDs, then displays what it found with clear warning labels.

When you click “Strip All Metadata,” the image is re-rendered through an HTML5 Canvas — which by design does not preserve EXIF data — and exported as a clean JPEG. The visual content is identical; the metadata is gone.

No server involved. No upload. The file never leaves your browser tab.

The Technical Architecture

PixelStrip doesn’t just run the image through a Canvas and re-export it (though that would strip EXIF data too). Instead, it parses the JPEG binary structure directly, which lets it show you exactly what metadata is present before removing anything. Here’s how the pipeline works at the code level.

A JPEG file is a sequence of binary segments, each starting with a two-byte marker. The image data lives in the SOS (Start of Scan) segment. Metadata lives in APP segments — specifically APP1 (0xFFE1), which contains the EXIF data. PixelStrip reads the file as an ArrayBuffer and walks through these segments to find and parse the EXIF block.

Inside the EXIF APP1 segment, data is organized as IFD (Image File Directory) entries — essentially key-value pairs. IFD0 contains basic image info (camera make, software). The GPS sub-IFD (linked from IFD0) contains the location tags: GPSLatitude, GPSLongitude, GPSAltitude, GPSTimeStamp, and others. Each IFD entry has a tag ID, a data type, a count, and either the value itself or an offset to where the value is stored.

Here’s a simplified example of reading EXIF data from a File object in the browser:

async function readExif(file) {
  const buffer = await file.arrayBuffer();
  const view = new DataView(buffer);

  // Verify JPEG magic bytes: 0xFFD8
  if (view.getUint16(0) !== 0xFFD8) {
    throw new Error('Not a JPEG file');
  }

  // Walk segments looking for APP1 (EXIF)
  let offset = 2;
  while (offset < view.byteLength) {
    const marker = view.getUint16(offset);
    if (marker === 0xFFE1) {
      // Found APP1 segment - parse EXIF
      const length = view.getUint16(offset + 2);
      const exifData = buffer.slice(offset + 4, offset + 2 + length);
      return parseExifIFD(new DataView(exifData));
    }
    // Skip to next segment
    const segLength = view.getUint16(offset + 2);
    offset += 2 + segLength;
  }
  return null; // No EXIF found
}

The parseExifIFD function then walks the IFD entries, reading tag IDs and extracting values. GPS coordinates are stored as rational numbers (numerator/denominator pairs) in degrees, minutes, and seconds format. Converting to decimal coordinates requires: degrees + minutes/60 + seconds/3600.

To strip the metadata, PixelStrip identifies the APP1 segment boundaries and reconstructs the JPEG without it — copying the SOI marker, skipping APP1, and then copying all remaining segments (DQT, SOF, DHT, SOS, and the compressed image data) intact. The visual image data is never decoded or re-encoded, so there’s zero quality loss.

Why Client-Side Processing Matters

The irony of most metadata removal tools is hard to overstate: they ask you to upload your photo to their server to remove the data that reveals your location. You’re sending your GPS coordinates to a third party in order to prevent third parties from seeing your GPS coordinates.

PixelStrip’s architecture eliminates this entirely. The processing pipeline runs 100% in your browser:

• File API — reads the image from your local disk into JavaScript memory
• ArrayBuffer — provides raw binary access to parse JPEG segments
• Parse — walks the binary structure to find and display EXIF data
• Strip — reconstructs the JPEG without the APP1 (EXIF) segment
• Blob — wraps the clean binary data into a downloadable file
• Download — triggers a browser download with no network request

Open your browser’s Network tab while using PixelStrip. You’ll see zero outgoing requests after the initial page load. The JavaScript, CSS, and HTML are served once, cached by your browser, and everything after that happens locally. It even works in airplane mode.

Compare this to server-side alternatives like several popular EXIF removal websites. Their typical flow is: upload your image (sending your GPS data over the network), wait for server processing, download the stripped version. Even with HTTPS, your photo sits on their server during processing. Their privacy policy might say they delete it “promptly” — but you have no way to verify that. And if their server is compromised, your photos (with location data) are exposed.

Client-side processing isn’t just a privacy feature — it’s also faster. There’s no upload latency, no server queue, no download wait. Stripping metadata from a 5MB photo takes under 100ms locally. The same operation through a server-based tool takes 3-5 seconds minimum, most of that being network transfer time.

Building PixelStrip: Lessons Learned

I started this project after reading about a journalist whose source was identified through photo EXIF data. The source had sent photos to document conditions at a facility, and the GPS coordinates in those photos led directly back to them. That story stuck with me — not because the technology was exotic, but because the fix was so simple. Strip the metadata before sharing. The problem was that no tool made it easy to do privately.

Building a JPEG parser from scratch taught me that the JPEG binary format is messy in practice, even though the spec is straightforward in theory. Every camera manufacturer embeds EXIF slightly differently. Some use big-endian byte order, others use little-endian — and the byte order is specified per-segment, so you have to check it for each EXIF block. I spent an entire weekend debugging a parsing failure that turned out to be a Samsung phone embedding a non-standard MakerNote tag with its own internal IFD structure.

Some camera brands embed thumbnail images inside the EXIF data — a smaller version of the original photo. This is particularly dangerous because even if you crop a photo to remove something sensitive, the uncropped thumbnail might still be in the EXIF data. PixelStrip removes these thumbnails along with everything else in the APP1 segment.

Browser memory limits were another challenge. JavaScript’s ArrayBuffer works great for typical photos (2-10MB), but panoramic shots and RAW-converted JPEGs can exceed 30MB. On mobile browsers with limited memory, loading a 30MB file into an ArrayBuffer while also keeping the original for display can cause the tab to crash. I added a file size check that warns users about very large files and processes them in chunks when possible.

Testing was the most time-consuming part. I collected sample photos from every major smartphone brand — Apple, Samsung, Google, OnePlus, Xiaomi, Huawei — because each manufacturer embeds EXIF differently. Apple’s format is clean and consistent. Samsung adds proprietary MakerNote fields. Google Pixel phones embed detailed lens calibration data. Each one required testing to make sure PixelStrip could identify and strip all metadata tags without corrupting the image data.

The most satisfying moment was running a stripped photo through ExifTool and seeing No EXIF data found. That’s the standard I hold PixelStrip to: not “most metadata removed” but “all metadata removed, verified by an independent tool.” If ExifTool can’t find it, neither can anyone else.

Who This Is For

• Online sellers — don’t leak your home address through product photos
• Freelancers & agencies — strip client metadata before handing off deliverables
• Privacy-conscious individuals — clean photos before posting anywhere
• Journalists & researchers — protect source locations and device identities
• Parents — remove geotags from family photos shared in group chats

Try It

👉 pixelstrip.orthogonal.info

Drop a photo. See what’s hiding. Strip it. Download. Takes about three seconds.

Related Privacy Tools

• What Is EXIF Data? Remove It Before Sharing — Deep dive into photo metadata risks
• QuickShrink: Browser Image Compressor — Compress images locally after stripping metadata
• Browser Fingerprinting: How Sites Track You — Another privacy threat beyond EXIF

References

• CIPA EXIF Standard (DC-008) — Official specification for Exchangeable Image File Format metadata in digital photos.
• File API — MDN — Browser API for reading files client-side without server uploads.
• ExifTool by Phil Harvey — Comprehensive open-source tool for reading, writing, and editing image metadata.
• EFF Privacy Issues — Electronic Frontier Foundation resources on digital privacy and metadata risks.

I got tired of uploading personal photos to random websites just to shrink them. So I built QuickShrink — an image compressor that runs entirely in your browser. Your images never touch a server.

The Dirty Secret of “Free” Image Compressors

Go ahead and Google “compress image online.” You’ll find dozens of tools, all with the same pitch: drop your image, we’ll compress it, download the result.

Here’s what they don’t tell you: your photo gets uploaded to their server. A server in a data center you’ve never seen, governed by a privacy policy you’ve never read, in a jurisdiction you might not even recognize. That family photo (which might be broadcasting your GPS location), that screenshot of your bank statement, that product image for your client — it’s now sitting on someone else’s disk.

Some of these services explicitly state they delete uploads after an hour. Others are silent on the matter. A few have been caught in breaches. The point isn’t that they’re malicious — it’s that there’s no reason for the upload to happen in the first place.

The Canvas API Makes Servers Unnecessary

Modern browsers ship with the Canvas API — a powerful image processing engine built into Chrome, Firefox, Safari, and Edge. It can decode an image, manipulate its pixels, and re-encode it at any quality level. All of this happens in memory, on your device, using your CPU.

QuickShrink leverages this. When you drop an image:

1. The browser reads the file into memory (no network request)
2. A Canvas element renders the image at its native resolution
3. canvas.toBlob() re-encodes it as JPEG at your chosen quality (10%–100%)
4. You download the result directly from browser memory

Total data transmitted over the network: zero bytes.

Under the Hood: How Canvas API Compression Actually Works

To understand why browser-based compression works so well, it helps to know what JPEG compression actually does under the surface. It’s not just “make the file smaller” — it’s a multi-stage pipeline that exploits how human vision works.

JPEG compression works in five distinct stages:

1. Color space conversion (RGB → YCbCr). Your image starts as red, green, and blue channels. The encoder converts it into luminance (brightness) and two chrominance (color) channels. This separation is key — human eyes are far more sensitive to brightness than to color.
2. Chroma subsampling. Since our eyes barely notice color detail, the encoder reduces the resolution of the two color channels. A common scheme is 4:2:0, which halves the color resolution in both dimensions — cutting color data to 25% of its original size with almost no perceptible difference.
3. Discrete Cosine Transform (DCT) on 8×8 pixel blocks. The image is divided into 8×8 pixel blocks, and each block is transformed from spatial data (pixel values) into frequency data (patterns of light and dark). Low-frequency components represent smooth gradients; high-frequency components represent sharp edges and fine detail.
4. Quantization — this is where quality loss happens. The frequency data from each block is divided by a quantization matrix and rounded. High-frequency components (fine detail) get divided by larger numbers, effectively zeroing them out. This is the lossy step — and it’s where the quality parameter has its effect.
5. Huffman encoding. Finally, the quantized data is compressed using lossless Huffman coding, which replaces common patterns with shorter bit sequences. This is the same principle behind ZIP compression — no data is lost in this step.

When you call canvas.toBlob() with a quality parameter, the browser’s built-in JPEG encoder runs all of these steps. The quality parameter (0.0 to 1.0) controls step 4 — quantization. Lower quality means more aggressive quantization, which produces a smaller file but introduces more artifacts. Higher quality preserves more detail but results in a larger file.

Here’s how the browser’s compression maps to these steps in practice:

// The browser handles all the complexity behind this one call
canvas.toBlob(
  (blob) => {
    // blob is your compressed image
    console.log(`Compressed: ${blob.size} bytes`);
  },
  'image/jpeg',
  0.8  // quality: 0.0 (max compression) to 1.0 (no compression)
);

That single method call triggers the entire five-stage pipeline. The browser’s native JPEG encoder — written in optimized C++ and compiled to machine code — handles color conversion, DCT transforms, quantization, and Huffman coding. You get the output of a sophisticated compression algorithm through one line of JavaScript.

The Complete Compression Pipeline: File → Canvas → Blob → Download

Understanding the theory is useful, but let’s look at how the full pipeline works in practice. Here’s the complete compression function that QuickShrink uses at its core:

async function compressImage(file, quality = 0.8) {
  // Step 1: Read file into an Image object
  const img = await createImageBitmap(file);
  
  // Step 2: Create canvas at original dimensions
  const canvas = document.createElement('canvas');
  canvas.width = img.width;
  canvas.height = img.height;
  
  // Step 3: Draw image onto canvas
  const ctx = canvas.getContext('2d');
  ctx.drawImage(img, 0, 0);
  
  // Step 4: Re-encode as JPEG at target quality
  const blob = await new Promise(resolve => {
    canvas.toBlob(resolve, 'image/jpeg', quality);
  });
  
  // Step 5: Calculate savings
  const savings = ((file.size - blob.size) / file.size * 100).toFixed(1);
  console.log(`${file.name}: ${formatBytes(file.size)} → ${formatBytes(blob.size)} (${savings}% saved)`);
  
  return blob;
}

function formatBytes(bytes) {
  if (bytes === 0) return '0 B';
  const k = 1024;
  const sizes = ['B', 'KB', 'MB'];
  const i = Math.floor(Math.log(bytes) / Math.log(k));
  return parseFloat((bytes / Math.pow(k, i)).toFixed(1)) + ' ' + sizes[i];
}

The download trigger is equally straightforward — we create a temporary object URL, simulate a click on an anchor element, and immediately clean up:

function downloadBlob(blob, filename) {
  const url = URL.createObjectURL(blob);
  const a = document.createElement('a');
  a.href = url;
  a.download = filename.replace(/\.[^.]+$/, '_compressed.jpg');
  document.body.appendChild(a);
  a.click();
  document.body.removeChild(a);
  URL.revokeObjectURL(url); // free memory
}

The entire pipeline — from file selection to download — happens in under 500ms for a typical 3MB photo. No network round-trips, no upload progress bars, no waiting for a server to process your image. The bottleneck is your CPU’s JPEG encoder, which on any modern device is blazingly fast.

EXIF Data: The Privacy Metadata You Forgot About

Every photo your phone takes is embedded with invisible metadata called EXIF data. This includes GPS coordinates (often accurate to within a few meters), your camera model and serial number, the exact timestamp the photo was taken, and even the software used to edit it. If you’ve ever wondered how someone could figure out where a photo was taken — EXIF is the answer.

The amount of data stored in EXIF is staggering. A typical iPhone photo contains over 40 metadata fields: latitude and longitude, altitude, lens aperture, shutter speed, ISO, focal length, white balance, flash status, orientation, color space, and device-specific identifiers. Some Android phones even include the device’s unique hardware ID. When you share that photo — compressed or not — all of that metadata travels with it unless explicitly removed.

Here’s the problem: most “compress” tools keep EXIF data intact. Your compressed image still broadcasts your location, your device information, and your editing history. You think you’re just making a file smaller, but you’re passing along a dossier of metadata to whoever receives the image.

QuickShrink can show you what EXIF data exists in your image before stripping it. Here’s the code that reads EXIF markers from a JPEG file:

// Read EXIF data from JPEG to show user what's being removed
function readExifData(file) {
  return new Promise((resolve) => {
    const reader = new FileReader();
    reader.onload = function(e) {
      const view = new DataView(e.target.result);
      
      // JPEG starts with 0xFFD8
      if (view.getUint16(0) !== 0xFFD8) {
        resolve({ hasExif: false });
        return;
      }
      
      // Find EXIF marker (0xFFE1)
      let offset = 2;
      while (offset < view.byteLength) {
        const marker = view.getUint16(offset);
        if (marker === 0xFFE1) {
          resolve({
            hasExif: true,
            exifSize: view.getUint16(offset + 2),
            message: 'EXIF data found — GPS, camera info, timestamps will be stripped'
          });
          return;
        }
        offset += 2 + view.getUint16(offset + 2);
      }
      resolve({ hasExif: false });
    };
    reader.readAsArrayBuffer(file.slice(0, 128 * 1024)); // only read first 128KB
  });
}

When QuickShrink draws your image onto a Canvas and re-exports it, the Canvas API creates a brand new JPEG file. EXIF data from the original doesn’t carry over. This means compression through QuickShrink doubles as a privacy tool — your compressed photos won’t contain GPS coordinates, camera serial numbers, or editing software metadata. If you want a dedicated tool for this, check out PixelStrip, which I built specifically for EXIF removal.

Benchmarks: Real Numbers From Real Photos

Theory is nice, but numbers are better. I ran a set of real-world photos through QuickShrink at three different quality levels to see how the compression performs across different image types:

A few patterns emerge from these numbers. Screenshots compress the most aggressively because they contain large areas of flat color and sharp text — patterns that JPEG’s DCT transform handles efficiently. The 8×8 pixel blocks in a screenshot often contain identical or near-identical values, which quantize down to almost nothing. Photos with complex textures (landscapes, aerials) still see significant savings, but the encoder has to work harder to preserve fine detail like grass, foliage, and water ripples.

Notice that even at 40% quality, the drone aerial drops from 12.3 MB to 1.6 MB — an 87% reduction. For web use, email, or social media, this is more than adequate. Most social platforms recompress your uploads anyway, so starting with a leaner file means faster uploads and less double-compression artifacting.

Want to run your own benchmarks? Here’s a function that tests multiple quality levels and prints a comparison table:

// Run your own benchmarks
async function benchmarkCompression(file) {
  const qualities = [0.9, 0.8, 0.7, 0.6, 0.5, 0.4, 0.3];
  const results = [];
  
  const img = await createImageBitmap(file);
  const canvas = document.createElement('canvas');
  canvas.width = img.width;
  canvas.height = img.height;
  const ctx = canvas.getContext('2d');
  ctx.drawImage(img, 0, 0);
  
  for (const q of qualities) {
    const start = performance.now();
    const blob = await new Promise(r => canvas.toBlob(r, 'image/jpeg', q));
    const time = (performance.now() - start).toFixed(1);
    
    results.push({
      quality: `${q * 100}%`,
      size: formatBytes(blob.size),
      saved: `${((file.size - blob.size) / file.size * 100).toFixed(1)}%`,
      time: `${time}ms`
    });
  }
  
  console.table(results);
  return results;
}

The sweet spot for most use cases is 70–80% quality. Below 60%, text in screenshots becomes noticeably fuzzy. Above 90%, you’re barely saving any space. I personally use 75% as the default in QuickShrink because it balances file size and visual quality for the widest range of image types.

The Results Are Surprisingly Good

At 80% quality (the default), most photos shrink by 40–60% with no visible degradation. At 60%, you’re looking at 70–80% reduction — still good enough for web use, email attachments, and social media. Only below 30% do you start seeing compression artifacts.

The interface shows you exact numbers: original size, compressed size, and percentage saved. No guessing.

It’s Also a PWA

QuickShrink is a Progressive Web App — one of several free browser tools that can replace desktop apps. On mobile, your browser will offer to “Add to Home Screen.” On desktop Chrome, you’ll see an install icon in the address bar. Once installed, it launches in its own window, works offline, and feels like a native app — because functionally, it is one.

The entire application is a single HTML file with inline CSS and JavaScript. No build tools, no framework, no dependencies. It loads in under 200ms on any connection.

Try It

👉 quickshrink.orthogonal.info

Open source, zero tracking, free forever. If you find it useful, share it with someone who’s still uploading their photos to compress them.

Frequently Asked Questions

References

• HTMLCanvasElement.toBlob() — MDN — Canvas API method for client-side image compression and format conversion.
• Image Optimization — web.dev — Google’s guide to image compression techniques and best practices.
• WebP Compression Techniques — Technical documentation on WebP lossy and lossless compression algorithms.
• File API — MDN — Browser API enabling local file processing without server-side uploads.

Why Every Tech Enthusiast Needs a Homelab

My homelab started with a single Raspberry Pi running Pi-hole. Today it’s a TrueNAS SCALE server with 64GB of ECC RAM, dual 10GbE NICs, and 60TB+ of ZFS storage running 30+ Docker containers. I’ve made plenty of expensive mistakes along the way—buying consumer gear I had to replace, undersizing my UPS, skipping ECC RAM to save $40. This guide is everything I wish someone had told me before I started.

🏠 My setup: TrueNAS SCALE on a custom build · 64GB ECC RAM · dual 10GbE NICs · 60TB+ ZFS storage · OPNsense on a Protectli vault · UPS-protected · 30+ Docker containers.

But here’s the catch: building a homelab can be overwhelming. With endless hardware options and configurations, where do you even start? Whether you’re a beginner or a seasoned pro, this guide will walk you through every step, from entry-level setups to advanced configurations. Let’s dive in.

Step 1: Entry-Level Hardware for Beginners

If you’re new to homelabs, starting with entry-level hardware is the smartest move. It’s cost-effective, simple to set up, and versatile enough to handle a variety of tasks.

The Raspberry Pi Revolution

The Raspberry Pi 5 is a big improvement in the world of single-board computers. With its quad-core processor, USB 3.0 support, and gigabit Ethernet, it’s perfect for running lightweight services like Pi-hole (network-wide ad-blocking), Home Assistant (smart home automation), or even a small web server.

# Install Docker on Raspberry Pi 5
curl -fsSL https://get.docker.com | sh
sudo usermod -aG docker $USER

# Run a lightweight web server
docker run -d -p 8080:80 nginx

With a power consumption of less than 15 watts, the Raspberry Pi 5 is an energy-efficient choice. Pair it with a high-quality microSD card or an external SSD for storage. If you’re feeling adventurous, you can even cluster multiple Raspberry Pis to create a Kubernetes lab for container orchestration experiments.

Other single-board computers like the Odroid N2+ or RockPro64 are excellent alternatives if you need more RAM or CPU power. These devices offer similar functionality with added expandability, making them ideal for slightly more demanding workloads.

Step 2: Centralized Storage for Your Data

As your homelab grows, you’ll quickly realize the importance of centralized storage. A Network Attached Storage (NAS) system is the backbone of any homelab, providing a secure and organized way to store, share, and back up your data.

Choosing the Right NAS

The Synology DS224+ NAS is a fantastic choice for beginners and pros alike. With support for up to 32TB of storage, hardware encryption, and Docker container integration, it’s perfect for hosting a Plex media server or automating backups.

# Set up a shared folder on a Synology NAS
ssh admin@your-nas-ip
mkdir /volume1/shared_data
chmod 777 /volume1/shared_data

If you prefer a DIY approach, consider repurposing old hardware or using a mini PC to build your own NAS. Tools like TrueNAS Core (formerly FreeNAS) make it easy to create a custom storage solution tailored to your needs. DIY NAS setups offer unparalleled flexibility in terms of hardware selection, redundancy, and cost.

Expanding with Virtualization

Modern NAS devices often come with virtualization capabilities. For example, Synology NAS can run virtual machines directly, enabling you to host isolated environments for testing, development, or even gaming servers. This feature is a big improvement for anyone looking to maximize their homelab’s utility.

Step 3: Networking: The Homelab Backbone

Your network infrastructure is the glue that holds your homelab together. Consumer-grade routers might suffice for basic setups, but upgrading to prosumer or enterprise-grade equipment can significantly improve performance and reliability.

Routers and Firewalls

The UniFi Dream Machine is a top-tier choice for homelab networking. It combines a high-performance router, firewall, and network controller into a single device. Features like intrusion detection and prevention (IDS/IPS) and advanced traffic analytics make it ideal for managing complex network environments.

WiFi Coverage

For robust wireless coverage, the TP-Link Omada EAP660 HD is an excellent option. Its WiFi 6 capabilities ensure fast and stable connections, even in device-dense environments. Pair it with a managed switch for maximum flexibility.

Advanced users might consider segmenting their network using VLANs to isolate devices or services. For example, you could create separate VLANs for IoT devices, personal computers, and your NAS for improved security and organization.

Step 4: Compute Power for Advanced Workloads

As your homelab evolves, you’ll need more processing power for tasks like virtualization, container orchestration, and development. Mini PCs and small form factor servers are excellent options for scaling your compute resources.

Choosing a Mini PC

The Intel NUC 12 Pro is a powerhouse in a compact form factor. With support for Intel vPro, it excels at running multiple virtual machines or Kubernetes clusters. For budget-conscious users, the ASUS PN50 Mini PC offers excellent performance for most homelab tasks at a lower price point.

Container Orchestration

Once you have sufficient compute power, container orchestration tools like Kubernetes or Docker Swarm become invaluable. They allow you to manage multiple containers across your devices efficiently. Here’s an example Kubernetes deployment:

# Example Kubernetes deployment for an NGINX service:
apiVersion: apps/v1
kind: Deployment
metadata:
 name: nginx-deployment
spec:
 replicas: 2
 selector:
 matchLabels:
 app: nginx
 template:
 metadata:
 labels:
 app: nginx
 spec:
 containers:
 - name: nginx
 image: nginx:1.21
 ports:
 - containerPort: 80

Step 5: Optimizing Storage Performance

Fast and reliable storage is essential for a high-performing homelab. For boot drives and high-transaction workloads, SSDs are the way to go.

Choosing the Right SSD

The Samsung 980 Pro 2TB SSD is a standout choice. Its NVMe interface delivers blazing-fast read/write speeds, making it ideal for databases, Docker images, and operating systems. SSDs ensure quicker boot times and smoother application performance, especially for tasks like video editing or compiling code.

Step 6: Security and Remote Access

Exposing your homelab to the internet comes with risks. Prioritizing security is non-negotiable.

Two-Factor Authentication

The YubiKey 5C NFC is an excellent hardware security key for adding 2FA to your accounts and services. It’s compatible with SSH, GitHub, and Google Workspace.

VPN and Remote Access

Set up a VPN server to securely access your homelab from anywhere. WireGuard is a lightweight and fast option. Here’s a basic installation example:

# Install WireGuard on Debian/Ubuntu
sudo apt update
sudo apt install wireguard

# Generate keys
wg genkey | tee privatekey | wg pubkey > publickey

Quick Summary

• Start small with affordable hardware like the Raspberry Pi 5 and scale as needed.
• Centralize your data with a pre-built NAS or DIY solution using TrueNAS Core.
• Invest in enterprise-grade networking gear for stability and scalability.
• Use mini PCs or small servers to handle compute-intensive tasks.
• Prioritize security with 2FA, VPNs, and regular updates.
• Document everything—network configurations, IP addresses, and passwords are vital for troubleshooting.

A homelab is a journey, not a destination. Whether you’re self-hosting personal services, learning enterprise-grade technologies, or simply tinkering with hardware, the possibilities are endless. Start small, experiment, and enjoy the process of building something truly your own.

Where to Start

Don’t build my setup on day one—I certainly didn’t. Start with a Raspberry Pi or an old laptop running TrueNAS Core. Add a managed switch when you’re ready for VLANs. Upgrade to ECC RAM and proper server hardware only when you know your workload demands it. The most important thing is to start, learn, break things, and iterate. My homelab has been rebuilt three times and I don’t regret a single weekend I spent on it.

Frequently Asked Questions

References

• TrueNAS Documentation — Official documentation for the TrueNAS storage platform.
• ServeTheHome — Expert reviews and guides for server and homelab hardware.
• PCPartPicker — Hardware compatibility checker for building custom server configurations.
• Ubiquiti Introduction — Networking equipment commonly used in professional homelab setups.

This is the exact hardware stack I use daily. Every recommendation here is something I’ve personally tested across years of development, security work, and running a 30+ container homelab. The right hardware isn’t just about speed—it’s about creating an environment that enhances focus, minimizes frustration, and maximizes productivity. Let’s dive deep into building the ultimate development setup for 2026.

Blazing Fast Storage: The Backbone of Productivity

Sluggish storage is the silent killer of developer efficiency. Whether you’re compiling code, running virtual machines, or handling large datasets, your storage solution directly impacts performance. Speed isn’t just a luxury—it’s essential.

Why NVMe SSDs Are Non-Negotiable

Modern NVMe SSDs offer unparalleled speeds compared to older SATA drives. They’re a big improvement for tasks like container builds, database transactions, and managing large projects with thousands of files.

Recommended SSDs for Developers:

• Samsung 980 Pro 2TB NVMe SSD: Industry-leading speed (~$130-180).
• Western Digital SN850X 2TB NVMe SSD: Budget-friendly without sacrificing performance (~$150-200).

Both drives boast read speeds up to 7,000 MB/s. For comparison, traditional SATA SSDs max out at around 550 MB/s. In my own experience, switching from SATA to NVMe reduced Docker build times by nearly 40% for large projects.

Optimizing Storage for Development

If you’re juggling multiple development environments—such as running Docker containers alongside virtual machines—storage speed and organization become critical. Here’s how you might partition an NVMe SSD:

# Partition NVMe SSD into 3 sections: OS, workspace, and backups
sudo parted /dev/nvme0n1 mklabel gpt
sudo parted /dev/nvme0n1 mkpart primary ext4 0% 40%
sudo parted /dev/nvme0n1 mkpart primary ext4 40% 80%
sudo parted /dev/nvme0n1 mkpart primary ext4 80% 100%

For developers dealing with sensitive data, consider encrypting your SSD partitions using tools like dm-crypt or BitLocker.

Keyboards and Mice: Your Daily Companions

You’ll spend countless hours interacting with your keyboard and mouse. These aren’t just peripherals; they’re tools that directly affect your comfort and productivity. A poorly designed keyboard can lead to wrist strain and fatigue, while a sluggish mouse can slow you down.

Mechanical Keyboards

Mechanical keyboards offer superior tactile feedback, durability, and customization options compared to membrane keyboards. For developers, the ability to type quickly and accurately is critical.

• Keychron K3 Mechanical Keyboard: Compact, low-profile, and portable (~$75-95).
• Das Keyboard 4 Professional: Premium build quality and unparalleled typing experience (~$150-200).

Consider switches carefully—mechanical keyboards offer a variety of switches, such as Cherry MX Browns for balanced tactile feedback or Cherry MX Reds for smooth keystrokes. If you’re working in shared spaces, opt for quieter switches or O-rings to dampen noise.

Precision Mice

For a developer, the mouse needs to be precise, ergonomic, and customizable. The Logitech MX Master 3S is my go-to choice for coding and general productivity.

Features:

• Customizable side buttons for IDE shortcuts.
• Infinite scroll wheel for navigating long code files.
• Ergonomic design for extended use.

If you prefer a simpler mouse, the Razer Basilisk X Hyperspeed offers excellent wireless performance and a sleek profile at a lower price (~$60-80).

Displays: The Window to Your Code

A high-quality monitor setup makes multitasking seamless. With a larger screen (or dual monitors), you can avoid constant alt-tabbing and keep your IDE, terminal, browser, and documentation open simultaneously.

Monitor Recommendations

• LG 27UP850-W 4K Monitor: Stunning 4K resolution with USB-C support (~$350-400).
• Dell UltraSharp U2723QE: Factory-calibrated for color accuracy (~$450-500).

For maximum productivity, consider a dual-monitor setup. Here’s how to configure it on Linux:

# Configure dual monitors using xrandr
xrandr --output HDMI-1 --primary --mode 3840x2160 --pos 0x0 --rotate normal
xrandr --output DP-1 --mode 1920x1080 --pos 3840x0 --rotate normal

Processing Power and Memory: The Engine of Your Setup

When choosing a processor and RAM, focus on your workload. Are you running multiple Docker containers, virtual machines, or machine learning models? If so, you’ll need higher specs.

Recommended RAM

• Crucial 64GB DDR4-3200: Ideal for heavy multitasking (~$180-220).
• Corsair Vengeance LPX 32GB DDR4: Perfect for mid-range setups (~$90-120).

For processors, aim for at least an AMD Ryzen 7 or Intel i7. Both offer excellent multi-core performance for compiling large projects or running virtualized environments.

Common Pitfalls

• Buying RAM without checking motherboard compatibility.
• Underestimating CPU cooling requirements for high-performance setups.

Security Hardware: Protecting Your Code

As developers, we’re prime targets for cyberattacks. Hardware-based security keys like the YubiKey 5C NFC provide an additional layer of protection against phishing and unauthorized access.

How to Set Up YubiKey with GitHub:

# Enable YubiKey for GitHub
1. Go to GitHub Settings > Security > Two-factor Authentication.
2. Select 'Security key' and follow the prompts.
3. Insert your YubiKey and tap to verify.

Homelab Hardware for Self-Hosting

🔧 From my experience: I run Gitea, Immich, Nextcloud, and a full trading system on a TrueNAS box with 64 GB ECC RAM and mirrored NVMe. ECC RAM is non-negotiable for anything running 24/7—I’ve seen bit-flip errors corrupt a ZFS pool on non-ECC memory. Spend the extra $40.

Self-hosting tools like GitLab, Jenkins, or databases can give you greater control and privacy. Here are two excellent hardware options:

• Intel NUC 12 Pro Mini PC: Perfect for heavy workloads (~$450-550).
• Raspberry Pi 5: Affordable and great for lightweight services (~$75-85).

Sample Docker Configuration for Homelabs

# Run a local development database using Docker
docker run --name dev-postgres -e POSTGRES_PASSWORD=mysecurepassword -d -p 5432:5432 postgres

Quick Summary

• Prioritize fast NVMe storage for immediate productivity gains.
• Invest in ergonomic keyboards and mice for long-term comfort.
• Use 4K monitors or dual setups for multitasking efficiency.
• Upgrade RAM and CPUs based on your workload requirements.
• Add hardware security keys to safeguard your accounts and codebases.
• Consider self-hosting development tools for privacy and control.

📚 Related Articles

• Home Network Segmentation with OPNsense: A Complete Guide
• Ultimate Guide to Secure Remote Access for Your Homelab
• How to Make HTTP Requests Through Tor with Python

References

• Visual Studio Code Documentation — Official docs for the most popular development IDE.
• MacBook Pro — Apple — Apple Silicon laptops widely used for professional software development.
• JetBrains IDE Documentation — Documentation for JetBrains professional development tools.
• Docker Desktop Documentation — Container runtime essential for modern development workflows.