Category: Tools & Setup

Last week I wanted to prove a point to a friend who insisted his vacation photos were “fine to post.” So I opened one of his JPEGs in a hex editor, scrolled about 40 bytes in, and read his hotel’s GPS coordinates straight off the screen — no tools, no library, just the raw bytes. That’s the thing nobody tells you about EXIF: it isn’t encrypted, hashed, or hidden. It’s sitting near the front of almost every photo your phone takes, in a format you can decode by hand once you know the layout. This post is the byte-level teardown, and at the end I’ll show why PixelStrip removes that data without touching a single pixel.

A JPEG is just a stream of markers

Every JPEG starts with two bytes: FF D8, the Start Of Image marker. After that the file is a sequence of segments, and every segment begins with FF followed by a marker byte. The one we care about is FF E1 — that’s APP1, where EXIF lives.

Here’s the front of a real photo, annotated:

FF D8              SOI (start of image)
FF E1              APP1 marker  <- EXIF starts here
00 84              segment length = 0x0084 = 132 bytes (big-endian, always)
45 78 69 66 00 00  "Exif\0\0"
49 49              "II" = Intel / little-endian byte order
2A 00              42, the TIFF magic number
08 00 00 00        offset to first IFD = 8

Two details trip people up here. First, that segment-length field is always big-endian, because it’s part of the JPEG container, not the EXIF payload. Second, the byte order flag (II for little-endian, MM for big-endian) only applies to everything after the Exif\0\0 header. From that point on, every multi-byte number flips based on those two bytes.

The TIFF header and IFD entries

What follows Exif\0\0 is a tiny TIFF file. All internal offsets are measured from the start of the byte-order mark — not the start of the file. Forget that and every pointer you read lands in the wrong place. I’ve debugged this exact off-by-six error more times than I’d like to admit.

The 4-byte offset (here 08 00 00 00 = 8) points to the first Image File Directory, or IFD0. An IFD is dead simple:

• 2 bytes: how many entries follow
• 12 bytes per entry
• 4 bytes at the end: offset to the next IFD (0 means stop)

Each 12-byte entry breaks down as: a 2-byte tag ID, a 2-byte data type, a 4-byte value count, and a 4-byte field that holds either the value itself (if it fits in 4 bytes) or an offset to where the value actually lives. GPS coordinates don’t fit in 4 bytes, so they’re always stored by offset.

The tag we hunt for in IFD0 is 0x8825 — the GPS IFD pointer. Its value is an offset to a separate sub-directory holding the location tags. Jump there and you find the payload.

Decoding latitude by hand

The GPS sub-IFD uses a handful of tags. The important ones:

• 0x0001 GPSLatitudeRef — ASCII “N” or “S”
• 0x0002 GPSLatitude — three RATIONAL values: degrees, minutes, seconds
• 0x0003 GPSLongitudeRef — “E” or “W”
• 0x0004 GPSLongitude — three more RATIONALs

A RATIONAL is two 4-byte unsigned integers: a numerator followed by a denominator. So latitude is three of them — 24 bytes total. Here’s the actual block from that photo, little-endian:

25 00 00 00  01 00 00 00   ->  37 / 1   = 37 degrees
2E 00 00 00  01 00 00 00   ->  46 / 1   = 46 minutes
C4 0B 00 00  64 00 00 00   ->  3012 / 100 = 30.12 seconds

Convert degrees-minutes-seconds to decimal: 37 + 46/60 + 30.12/3600 = 37.7750° N. Pair that with the longitude block and you have a point accurate to roughly three meters. That’s precise enough to land on a specific building. My friend went quiet after I read his back.

A 40-line parser in the browser

You don’t need a library to do this. Browser DataView reads typed values out of an ArrayBuffer with explicit endianness, which is exactly what EXIF needs. Here’s the core of finding the APP1 segment and its byte order:

function findExif(view) {
  let offset = 2; // skip the FF D8 SOI
  while (offset < view.byteLength) {
    if (view.getUint8(offset) !== 0xFF) break;
    const marker = view.getUint8(offset + 1);
    const size = view.getUint16(offset + 2); // big-endian on purpose
    if (marker === 0xE1) {
      const tiff = offset + 10;            // skip marker, length, "Exif\0\0"
      const le = view.getUint16(tiff) === 0x4949; // "II"
      return { tiff, littleEndian: le, app1Start: offset, size };
    }
    offset += 2 + size; // jump to the next segment
  }
  return null;
}

Note that getUint16 defaults to big-endian, which is correct for the JPEG segment length. Once you have the littleEndian flag, you pass it to every read inside the TIFF block. Reading a RATIONAL is two reads and a divide:

function readRational(view, pos, le) {
  return view.getUint32(pos, le) / view.getUint32(pos + 4, le);
}

That’s the whole trick. Walk the IFD entries, find tag 0x8825, jump to the GPS sub-IFD, pull the latitude and longitude rationals, and apply the N/S/E/W sign. About 40 lines, no dependencies, runs offline.

Two ways to strip it — and why they differ

Now the part that actually matters. There are two ways to remove this metadata, and they are not equal.

Re-encode the whole image. Draw the photo onto a <canvas> and call toBlob(). The new file is built from raw pixels, so it carries no EXIF at all. Clean — but every pixel gets recompressed, which means slight quality loss and a completely different byte layout. That’s the approach my QuickShrink compressor takes, and I wrote up the mechanics in how browser image compression actually works. Good when you also want a smaller file.

Splice out the segment. If all you want is to delete the metadata and keep the image untouched, you cut the APP1 segment out of the byte stream and leave everything else identical:

const out = new Uint8Array(bytes.byteLength - (2 + size));
out.set(bytes.subarray(0, app1Start));
out.set(bytes.subarray(app1Start + 2 + size), app1Start);

The pixels stay bit-for-bit identical. No recompression, no quality loss, no visible change — just the location data gone. That’s what PixelStrip does.

One gotcha worth knowing: a single JPEG can carry more than one metadata block. EXIF lives in APP1, but XMP often rides in a second APP1, Photoshop data sits in APP13, and the EXIF thumbnail in IFD1 can hold its own copy of the GPS tags. A parser that removes only the first APP1 it sees will miss the rest. A real stripper loops over every APPn segment, which is the unglamorous part most “remove EXIF” snippets skip.

What to actually do with this

If you only remember one rule: platforms are inconsistent. Twitter and iMessage scrub metadata on upload; Discord, email attachments, Slack file shares, and most forums pass it through untouched. Assume the worst and clean photos before they leave your machine.

For a one-click clean that keeps your image quality intact, drop the photo into PixelStrip — it runs entirely in your browser, so the file never uploads anywhere, and it surgically removes EXIF, GPS, and XMP without recompressing. If you want the privacy reasoning rather than the byte layout, I covered that in how to strip EXIF data before sharing. The rest of the browser tools follow the same no-upload rule.

If you want to go deeper than a hex editor, file-format forensics books cover exactly this kind of byte-level metadata extraction across image, document, and filesystem formats — a solid digital forensics reference is what I keep on the shelf for the weird edge cases (full disclosure: Amazon affiliate link). It’s the difference between guessing at an offset and knowing why it’s there.

Join https://t.me/alphasignal822 for free market intelligence.

Last week a teammate asked me why our little browser tool, QuickShrink, could take a 4.2 MB phone photo and hand back a 380 KB file that looked identical — all without uploading a single byte to a server. He assumed there was some clever backend doing the heavy lifting. There isn’t. It’s about 40 lines of JavaScript and a browser API that has shipped in every major engine since roughly 2013. I want to walk through exactly what happens between the file picker and the download link, because once you understand it, you stop trusting upload-based compressors that ship your private photos to someone else’s box.

The whole pipeline is three steps

Browser image compression with the Canvas API comes down to: decode the image into pixels, paint those pixels onto a canvas, then re-encode the canvas at a chosen quality. That’s it. Here’s the core of what QuickShrink runs, stripped to the essentials:

async function compress(file, quality = 0.8) {
  // 1. Decode: turn the file bytes into a bitmap
  const bitmap = await createImageBitmap(file);

  // 2. Paint: draw the bitmap onto a canvas
  const canvas = document.createElement('canvas');
  canvas.width = bitmap.width;
  canvas.height = bitmap.height;
  const ctx = canvas.getContext('2d');
  ctx.drawImage(bitmap, 0, 0);

  // 3. Re-encode: read pixels back out as a compressed blob
  return new Promise((resolve) => {
    canvas.toBlob(resolve, 'image/jpeg', quality);
  });
}

The magic is in step three. When you call canvas.toBlob(callback, 'image/jpeg', 0.8), the browser runs its native JPEG encoder over the raw RGBA pixels sitting in the canvas buffer. That 0.8 is the quality factor, a number between 0 and 1, and it maps to the same quantization-table scaling that libjpeg uses under the hood. Lower the number, the encoder throws away more high-frequency detail, and the file shrinks.

Why the file gets smaller without looking worse

JPEG compression is lossy and it exploits a fact about human vision: we’re bad at noticing small changes in color and fine detail, but good at noticing changes in brightness and edges. The encoder splits the image into 8×8 pixel blocks, runs a discrete cosine transform on each, and then quantizes the result — rounding off the coefficients that represent detail your eye won’t miss.

The quality factor controls how aggressive that rounding is. At 0.92 you’re barely touching anything. At 0.8 you’ve cut the file roughly in half and almost nobody can tell in a blind test. Drop to 0.6 and you’ll start seeing ringing around hard edges — text on a screenshot is where it shows up first. I settled on 0.8 as the default after eyeballing a few hundred photos. It’s the knee of the curve where you get most of the size savings before quality visibly drops.

Real numbers from a real photo set

I ran a batch of 20 photos straight off a Pixel 8 — landscapes, indoor shots, a couple of screenshots — through the canvas pipeline at different quality settings. Average original size was 3.8 MB per file. Here’s what came out:

• quality 0.92 — avg 1.9 MB, about 50% reduction, visually lossless
• quality 0.80 — avg 720 KB, about 81% reduction, no visible loss on normal viewing
• quality 0.60 — avg 410 KB, about 89% reduction, slight softening on text edges
• quality 0.40 — avg 280 KB, about 93% reduction, obvious artifacts

The reason phone photos compress this well is that they start out barely compressed. Camera apps save at quality 0.95 or higher to avoid complaints, and they bake in fat EXIF blocks with GPS coordinates, lens data, and a full-size thumbnail. Re-encoding at 0.8 and dropping the metadata is where most of the savings come from. (If the metadata part interests you, I wrote a separate piece on how EXIF leaks your home address and how to strip it.)

The gotcha nobody warns you about: createImageBitmap vs Image

The old way to decode an image was to create an <img> element, set its src to an object URL, and wait for the onload event. It works, but it decodes on the main thread and blocks your UI while it runs. On a big panorama, that’s a visible freeze.

// Old way - blocks the main thread
const img = new Image();
img.onload = () => ctx.drawImage(img, 0, 0);
img.src = URL.createObjectURL(file);

createImageBitmap() is the better path. It decodes off the main thread, returns a promise, and gives you an ImageBitmap that draws to canvas faster because it’s already in a GPU-friendly format. On the 20-photo batch above, switching from the Image approach to createImageBitmap cut total processing time from 4.1 seconds to 1.6 seconds. If you build anything that compresses more than one file, use it.

One real gotcha: createImageBitmap ignores EXIF orientation by default. Photos shot in portrait can come out sideways. You fix it by passing { imageOrientation: 'from-image' } as the second argument, which most engines now honor:

const bitmap = await createImageBitmap(file, { imageOrientation: 'from-image' });

WebP is where the real wins are

JPEG is the safe default, but if you don’t need to email the file to someone on a 2014 device, WebP beats it badly. Same canvas, same code, you just change the MIME type:

canvas.toBlob(resolve, 'image/webp', 0.8);

On my test set, WebP at quality 0.8 came out to an average of 480 KB versus JPEG’s 720 KB at the same setting — another third smaller for the same perceived quality. Every browser shipped in the last six years decodes WebP, so the compatibility argument is mostly dead unless you’re targeting ancient hardware. The one place I still reach for JPEG is when the recipient is going to drag the file into some old desktop app that chokes on WebP.

Why “browser-only” is the part that matters

Here’s the bit I care about most. Because every step — decode, paint, re-encode — runs inside createImageBitmap and canvas.toBlob, the image never leaves the tab. There’s no fetch, no upload, no server log with your file sitting in it. You can literally open the network tab in DevTools, compress a photo, and watch zero requests fire. Pull your ethernet cable and it still works.

That’s not true of most “free online image compressor” sites. They POST your file to a backend, compress it there, and hand back a URL. Which means a copy of your photo — with its original GPS metadata if they don’t strip it — lives on a machine you don’t control, for however long their retention policy says, or doesn’t say. For a meme, who cares. For a photo of a document, a whiteboard with company internals, or a picture taken inside your house, that’s a real leak. I’ve gotten paranoid enough about this that I treat every upload-based dev tool as a potential logging endpoint, which is the same reason I wrote about why you should stop pasting sensitive data into online dev tools.

Try it, or build your own

If you just want the result, QuickShrink is the tool — drag a photo in, pick a quality, download. No account, no upload, no tracking. If you want to build your own, the code above is the whole idea; wrap it in a drag-drop handler and a quality slider and you’re done in an afternoon.

The hardware angle matters too. Canvas re-encoding is CPU-bound and single-image-fast, but if you batch-process hundreds of RAW or high-res files, a machine with more cores and fast storage makes the difference between seconds and minutes. I do my bulk photo work on an SSD-backed box, and a good portable drive like the Samsung T7 Shield portable SSD is what I use to shuttle large photo libraries between machines without waiting on a slow USB stick. Full disclosure: that’s an Amazon affiliate link — it’s the drive I actually use.

The takeaway: browser image compression isn’t magic and it isn’t a backend. It’s a 13-year-old canvas API, a quality number between 0 and 1, and the choice to keep your pixels on your own machine. Once you know how the pipeline works, the upload-based tools start looking like a strictly worse deal.

Join https://t.me/alphasignal822 for free market intelligence.

Last month I helped a friend figure out why a stalker knew her daily routine. The answer was in her Instagram stories — not the content, but the metadata baked into every JPEG she posted. GPS coordinates, timestamps accurate to the second, even her phone model. Instagram strips EXIF on upload, but she’d been sharing originals in a group chat first.

Most developers know EXIF exists. Fewer know exactly what’s in there, how to parse it programmatically, or how to strip it without degrading image quality. I spent a weekend building a browser-based EXIF stripper that never uploads your files, and learned more about the JPEG binary format than I expected.

What EXIF Actually Contains (It’s Worse Than You Think)

EXIF (Exchangeable Image File Format) lives in the APP1 marker segment of JPEG files, right after the SOI (Start of Image) marker at bytes 0xFFD8. The structure follows TIFF IFD (Image File Directory) format — a linked list of tagged key-value pairs.

Here’s what a typical iPhone photo contains:

GPS Latitude: 37.7749 N
GPS Longitude: 122.4194 W
GPS Altitude: 12.3m above sea level
DateTime Original: 2026:05:20 14:32:07
Make: Apple
Model: iPhone 15 Pro Max
Lens: iPhone 15 Pro Max back camera 6.765mm f/1.78
Software: 18.4.1
Orientation: Rotate 90 CW
Focal Length: 6.765mm (equiv 24mm)
Exposure: 1/120s at f/1.78, ISO 50
Unique Image ID: 4A3B2C1D-...

That’s 40+ fields in a single photo. The GPS data alone is accurate to about 3 meters with modern phones. Post enough photos from your apartment and anyone with exiftool can pinpoint your building.

The Binary Structure: Parsing EXIF in JavaScript

If you want to strip EXIF without re-encoding (which would lose quality), you need to understand the byte layout. A JPEG with EXIF looks like this:

FF D8          - SOI marker (Start of Image)
FF E1 [len]   - APP1 marker (EXIF data lives here)
  45 78 69 66 00 00  - "Exif\0\0" header
  [TIFF header + IFD entries + GPS sub-IFD]
FF E0 [len]   - APP0 marker (JFIF, optional)
FF DB [len]   - DQT (quantization tables)
FF C0 [len]   - SOF (frame header)
...            - actual image data
FF D9          - EOI marker

The key insight: you can remove the entire APP1 segment without touching image pixels. The compressed image data starts at SOF and is completely independent of the metadata. Here’s the core logic I use:

function stripExif(arrayBuffer) {
  const view = new DataView(arrayBuffer);
  if (view.getUint16(0) !== 0xFFD8) return arrayBuffer;

  const segments = [];
  let offset = 2;

  while (offset < view.byteLength) {
    const marker = view.getUint16(offset);
    if (marker === 0xFFDA) {
      segments.push(arrayBuffer.slice(offset));
      break;
    }
    const segLen = view.getUint16(offset + 2);
    if (marker !== 0xFFE1 && marker !== 0xFFED) {
      segments.push(arrayBuffer.slice(offset, offset + 2 + segLen));
    }
    offset += 2 + segLen;
  }

  const soi = new Uint8Array([0xFF, 0xD8]);
  const parts = [soi, ...segments.map(s => new Uint8Array(s))];
  const result = new Uint8Array(parts.reduce((a, p) => a + p.length, 0));
  let pos = 0;
  for (const part of parts) {
    result.set(part, pos);
    pos += part.length;
  }
  return result.buffer;
}

This approach is lossless — zero re-encoding, zero quality loss. The output file is typically 5-50KB smaller than the input because you’re removing the metadata block entirely.

Why “Browser-Only” Matters for This

Think about the irony: you want to strip location data from your photos for privacy… so you upload them to a random website? That site now has your original files, complete with GPS coordinates, before stripping anything.

I built the orthogonal.info image tool to process everything client-side using the Canvas API and ArrayBuffer manipulation. Your files never leave your browser tab. Verify by opening DevTools Network tab — zero upload requests during processing.

const file = input.files[0];
const buffer = await file.arrayBuffer();
const stripped = stripExif(buffer);
const blob = new Blob([stripped], { type: 'image/jpeg' });
const url = URL.createObjectURL(blob);

What About PNG and WebP?

PNG stores metadata differently — in tEXt, iTXt, and eXIf chunks rather than APP1 markers. The chunk-based format makes it straightforward to filter: read each chunk’s 4-byte type identifier, skip the ones you don’t want, concatenate the rest.

WebP uses RIFF container format with an EXIF chunk. Same principle: parse chunks, drop the EXIF one, rebuild.

Tools I Actually Use

For batch processing on my homelab, I use exiftool:

# Strip ALL metadata from every JPEG in a directory
exiftool -all= -overwrite_original *.jpg

# Keep orientation (so photos display correctly) but strip everything else
exiftool -all= -tagsfromfile @ -Orientation -overwrite_original *.jpg

That second command is important — if you strip the Orientation tag, portrait photos will display sideways in some viewers. Common gotcha.

For quick one-off checks before sharing, I use our browser-based tool — compress and strip in one step, no install needed. For developers building apps that handle user uploads, the piexifjs library (3KB gzipped) handles read/write/strip operations well.

If you’re processing images on a server, a Raspberry Pi 5 running an exiftool batch script works great as a dedicated metadata sanitizer on your network — keeps processing local and costs about $80 total with a case and SD card.

Platforms That Strip vs. Don’t

I tested 12 platforms in May 2026:

Strip EXIF on upload: Instagram, Twitter/X, Facebook, LinkedIn, Discord, iMessage

Preserve EXIF (danger zone): Email attachments, Signal (original quality), Telegram (as file), Google Drive, Dropbox shared links, most forum software

Signal strips EXIF when you send as a compressed photo, but preserves everything when you tap “original quality.” Most people don’t realize the distinction. Telegram behaves the same way: compressed = stripped, sent as file = full metadata intact.

The Real Risk Model

For most people, the threat isn’t nation-state actors. It’s:

• Selling items online with photos taken at home (Craigslist, Facebook Marketplace)
• Sharing “original quality” photos in group chats with acquaintances
• Uploading images to forums, bug trackers, or documentation sites
• Dating app photos with location data if the platform doesn’t strip

A privacy screen protector stops shoulder-surfers, but EXIF metadata is the silent leak most people never think about. Strip it before sharing. Every time.

If you handle images in any application — whether it’s a side project or production — add EXIF stripping to your upload pipeline. It’s 20 lines of code and it protects your users from themselves.

Related: Developer Tools Guide | DevSecOps in Practice

Join Alpha Signal for free market intelligence — daily signals, no spam.

Last month I needed real-time-ish stock quotes for a personal trading dashboard. Nothing fancy — just current prices, daily OHLCV, and maybe some basic fundamentals. I figured this would take an afternoon. It took a week, because every “free” market data API has a different definition of “free.”

I tested Polygon.io, Finnhub, Alpha Vantage, and yfinance (the unofficial Yahoo Finance wrapper) for a simple use case: pull 30 tickers every 5 minutes during market hours, store the data in SQLite, and trigger alerts on volume spikes. (For an event-driven variant, see how I built a Python alerter for SEC insider buying.)

The Test Setup

I wrote the same data pipeline four times — one per API. Each version pulls price data for 30 S&P 500 stocks, handles rate limits gracefully, and logs failures. The code ran on a $5 VPS for two weeks straight.

import requests
import time
from datetime import datetime

TICKERS = ["AAPL", "MSFT", "NVDA", "GOOGL", "AMZN", ...]  # 30 total

def fetch_polygon(ticker, api_key):
    url = f"https://api.polygon.io/v2/aggs/ticker/{ticker}/prev"
    r = requests.get(url, params={"apiKey": api_key})
    if r.status_code == 429:
        time.sleep(12)  # free tier: 5 calls/min
        return fetch_polygon(ticker, api_key)
    return r.json()["results"][0]

Polygon.io — Best Docs, Painful Rate Limits

Polygon’s free tier gives you 5 API calls per minute. For 30 tickers, that’s 6 minutes minimum per refresh cycle. Their docs are excellent — OpenAPI spec, clear error codes, consistent response formats. The data quality is solid; I never got a stale quote during market hours.

The catch: 5 calls/min means you’re always waiting. I ended up batching with their grouped daily endpoint (/v2/aggs/grouped/locale/us/market/stocks/{date}) which returns all tickers in one call. That’s the move if you’re on the free plan.

Verdict: Best API design. Use the grouped endpoints and you can work within 5 calls/min. Paid plan ($29/mo) removes limits entirely.

Finnhub — Generous Limits, Quirky Data

Finnhub gives you 60 calls/min on the free tier. That’s 12x Polygon’s allowance. I could refresh all 30 tickers in under a minute with room to spare.

def fetch_finnhub(ticker, api_key):
    url = "https://finnhub.io/api/v1/quote"
    r = requests.get(url, params={"symbol": ticker, "token": api_key})
    data = r.json()
    return {
        "price": data["c"],      # current
        "open": data["o"],
        "high": data["h"],
        "low": data["l"],
        "prev_close": data["pc"],
        "volume": data.get("v")  # sometimes missing!
    }

The issue: volume data was missing or zero for about 8% of my calls during the first hour of trading. Pre-market data is inconsistent. And their WebSocket (which is real-time on free tier!) occasionally drops connection without sending a close frame, so your reconnect logic needs to be reliable.

Verdict: Best free tier for polling frequency. The free WebSocket is genuinely useful for real-time dashboards. Just validate your data — don’t trust volume numbers before 10:30 AM ET.

Alpha Vantage — The OG That’s Showing Its Age

Alpha Vantage has been around forever. Free tier: 25 calls/day. Yes, per day, not per minute. They recently slashed this from 500/day (which was already tight).

25 calls/day is useless for anything beyond a daily cron job checking your portfolio at close. I couldn’t even pull all 30 tickers once. The response format is also uniquely annoying — keys like “1. open” and “2. high” instead of just “open” and “high.”

# Alpha Vantage response format... why?
{
    "Global Quote": {
        "01. symbol": "AAPL",
        "02. open": "189.5100",
        "05. price": "191.2400",
        # seriously, numbered string keys?
    }
}

Verdict: Skip it in 2026. The rate limits make it impractical for anything but the simplest daily check. The API design feels stuck in 2015.

yfinance — Free But Fragile

yfinance is an unofficial Python library scraping Yahoo Finance. No API key needed. No rate limits (sort of). Sounds perfect, right?

It broke twice during my two-week test. Yahoo changes their page structure, the library stops working, someone pushes a fix to PyPI in a day or two. For a personal project you check occasionally, that’s fine. For anything running unattended, it’s a liability.

import yfinance as yf

# Simple, but fragile
ticker = yf.Ticker("AAPL")
hist = ticker.history(period="1d", interval="5m")
# Works great until it doesn't

When it works, the data is rich — splits, dividends, options chains, financials, all free. The download() function handles batching natively. But I wouldn’t build anything I can’t babysit on top of it.

Verdict: Best for Jupyter notebooks and research. Don’t put it in a cron job you want to forget about.

My Actual Setup (What I Ended Up Using)

I use Finnhub’s WebSocket for real-time price updates during market hours, Polygon’s grouped daily endpoint for end-of-day OHLCV, and yfinance for fundamentals data I pull once a week. Three APIs, each doing what it does best.

import websocket
import json

def on_message(ws, message):
    data = json.loads(message)
    for trade in data.get("data", []):
        price = trade["p"]
        symbol = trade["s"]
        volume = trade["v"]
        # write to SQLite, check alerts
        check_volume_spike(symbol, volume)

ws = websocket.WebSocketApp(
    f"wss://ws.finnhub.io?token={FINNHUB_KEY}",
    on_message=on_message,
    on_error=lambda ws, e: reconnect(ws),
)

Total cost: $0/month. The tradeoff is maintenance — when yfinance breaks or Finnhub drops connections, I fix it manually. If I valued my time at $50/hr, Polygon’s $29/mo plan would pay for itself in the first week.

Quick Comparison

Polygon.io Free: 5 calls/min, excellent docs, 15-min delayed quotes, best for batch daily data
Finnhub Free: 60 calls/min + free WebSocket, good data (watch pre-market volume), best for real-time
Alpha Vantage Free: 25 calls/day, outdated format, skip it
yfinance: No limits but breaks periodically, rich data, best for research notebooks

What I’d Recommend

If you’re building a trading dashboard or alert system, start with Finnhub. The 60 calls/min and free WebSocket give you the most room to experiment. Once you know your architecture works, consider Polygon’s paid tier for reliability.

If you’re doing backtesting or research, yfinance is hard to beat for the price (free). Just pin your dependency version and keep a fallback data source.

For the actual trading execution side, I’ve been using Alpaca’s API which has its own market data included with a brokerage account — that’s a separate topic I covered recently.

If you’re running this kind of setup on a home server, a Beelink Mini PC (affiliate link) draws about 15W and handles multiple Python processes and SQLite without breaking a sweat. I’ve been running mine 24/7 for months. A CyberPower UPS (affiliate link) keeps it alive through power blips — lost data during a brownout once, never again.

For monitoring your API pipeline, I keep a Grafana dashboard tracking call counts, error rates, and data freshness. A portable second monitor (affiliate link) dedicated to dashboards saves constant window-switching.

📡 I share trading signals and market intelligence daily in my free Telegram channel. If you’re building trading tools, the context helps. Join https://t.me/alphasignal822 for free market intelligence.