DEV Community: Truman

Your browser can detect your NAT type in 30 lines of JavaScript

Truman — Thu, 08 Oct 2026 17:50:46 +0000

Your browser can detect your NAT type in 30 lines of JavaScript

Ever had a video call that connects fine on one network but refuses to establish peer-to-peer on another? Or a game where voice chat works for everyone except that one friend? Nine times out of ten, the culprit is the NAT sitting between you and the internet — and your browser already has everything needed to interrogate it.

The 30-line version

async function probeNat(stunUrl) {
  const pc = new RTCPeerConnection({ iceServers: [{ urls: stunUrl }] });
  pc.createDataChannel('probe'); // kick off ICE gathering
  const srflx = await new Promise((resolve) => {
    const found = [];
    pc.onicecandidate = (e) => {
      if (e.candidate && e.candidate.candidate.includes('srflx'))
        found.push(e.candidate.candidate);
      else if (!e.candidate) resolve(found); // null = gathering done
    };
    setTimeout(() => resolve(found), 5000);
  });
  pc.close();
  return srflx;
}

const [a, b] = await Promise.all([
  probeNat('stun:stun.l.google.com:19302'),
  probeNat('stun:stun1.l.google.com:19302'),
]);

const portOf = (c) => c.split(' ')[5];
console.log(portOf(a[0]) === portOf(b[0])
  ? 'Cone NAT (predictable mapping)'
  : 'Symmetric NAT (per-destination mapping)');

That's it. No extensions, no native code, no permissions prompt. Let me explain why this works.

ICE candidates are a free STUN client

When you create an RTCPeerConnection with STUN servers configured, the browser's ICE agent automatically sends STUN Binding Requests to each server. The responses come back to your JavaScript as ICE candidates — strings like:

candidate:8421630493 1 udp 1685987071 203.0.113.45 54321 typ srflx raddr 192.168.1.5 rport 54321

The fields that matter: 203.0.113.45 54321 is your server-reflexive address — how the STUN server saw you after your NAT translated the packet. The raddr/rport pair is your local address behind the NAT. The typ srflx marker tells you this candidate came from STUN rather than local interface enumeration (host) or a TURN relay (relay).

So the browser is effectively a STUN client already. We're just reading its output.

The core trick: compare mappings across servers

A NAT has to decide what external port to assign your traffic. There are two philosophies:

Cone NAT: one internal address:port always maps to the same external address:port, regardless of destination. Ask two different STUN servers and both report the same external port.
Symmetric NAT: each destination gets its own mapping. Ask two different STUN servers and you get two different external ports.

That's exactly what the snippet compares. Same port from both servers → cone family. Different ports → symmetric. This single distinction predicts most real-world connectivity pain: with symmetric NAT, the other peer can never guess which port to send to, so direct P2P hole punching fails and everything falls back to TURN relay (higher latency, server bandwidth).

What you can't tell from the browser alone

Honesty corner: this trick separates cone from symmetric, but it can't split the cone family further. Telling Full Cone apart from Address-Restricted or Port-Restricted Cone requires probing — having a second server send packets at you from an address or port you never contacted, and seeing if they get through. Browsers can't receive arbitrary unsolicited UDP, so that test needs infrastructure outside the page. Most browser-based NAT tests (including the one linked below) report the cone/symmetric verdict and treat the cone subtypes as one bucket. For diagnosing "why won't my P2P connect," that bucket is usually enough.

Why this matters beyond curiosity

Hole punching — the technique WebRTC, game netcode, and tools like Tailscale rely on — only works when at least one side has a predictable mapping. If both sides sit behind symmetric NATs, direct connection is essentially impossible and you must relay. Knowing your NAT type up front tells you whether to even attempt P2P, what TURN capacity to provision, and why that one user keeps filing "call won't connect" tickets from their mobile hotspot.

Wrapping up

The whole technique is: configure STUN servers → harvest srflx candidates → compare external ports across servers. The browser does the hard protocol work; you just read the results.

If you'd rather not wire up the comparison logic yourself, 17NAS NAT Test runs exactly this probe in your browser — it queries multiple STUN servers, compares the mappings, and reports your NAT type with the raw candidate details. Free, no sign-up, everything happens client-side.

YouTube thumbnails are just predictable URLs: how maxresdefault really works

Truman — Thu, 08 Oct 2026 05:43:05 +0000

YouTube thumbnails are just predictable URLs: how maxresdefault really works

Every YouTube video has a set of thumbnail images sitting on a public CDN, no API key required. If you've ever built a tool that shows link previews, embeds videos, or lets users download covers, you've probably used them. This post explains the URL scheme, the size ladder, and the one gotcha that breaks naive implementations: maxresdefault doesn't always exist.

The URL scheme

All thumbnails live under:

https://i.ytimg.com/vi/{VIDEO_ID}/{SIZE}.jpg

{VIDEO_ID} is the 11-character ID from the watch URL. {SIZE} is one of:

Name	Resolution	Notes
`default`	120×90	Always exists, 4:3
`mqdefault`	320×180	Always exists, 16:9
`hqdefault`	480×360	Always exists, 4:3
`sddefault`	640×480	Usually exists, 4:3
`maxresdefault`	1280×720	Only if the video has an HD source

The pattern is simple enough to construct by hand. The catch is the last row: YouTube only generates maxresdefault when the uploaded video was HD. For older or low-resolution uploads, requesting it returns a 404 — or worse, a placeholder image with an HTTP 200, depending on the era of the upload. A robust fetcher must probe from largest to smallest and take the first that actually resolves.

Extracting the video ID

Users paste all kinds of URLs. Before you can build the thumbnail URL, you need the ID out of:

https://www.youtube.com/watch?v=dQw4w9WgXcQ
https://youtu.be/dQw4w9WgXcQ
https://www.youtube.com/shorts/dQw4w9WgXcQ
https://www.youtube.com/embed/dQw4w9WgXcQ
https://www.youtube.com/live/dQw4w9WgXcQ
https://m.youtube.com/watch?v=dQw4w9WgXcQ&feature=shared
just dQw4w9WgXcQ (11 chars)

A single regex handles most of these:

function extractVideoId(input) {
  const s = input.trim();
  if (/^[a-zA-Z0-9_-]{11}$/.test(s)) return s; // bare ID
  const m = s.match(
    /(?:youtube\.com\/(?:watch\?[^#]*v=|shorts\/|embed\/|live\/|v\/)|youtu\.be\/)([a-zA-Z0-9_-]{11})/
  );
  return m ? m[1] : null;
}

Note the character class: YouTube IDs are base64url, so - and _ are valid. A regex limited to [a-zA-Z0-9] will silently fail on roughly a quarter of videos.

Picking the best available size

The reliable approach is a fallback chain. In the browser, the cheapest probe is an Image load with onerror:

const SIZES = ['maxresdefault', 'sddefault', 'hqdefault', 'mqdefault', 'default'];

function bestThumbnail(videoId) {
  return new Promise((resolve) => {
    let i = 0;
    const tryNext = () => {
      if (i >= SIZES.length) return resolve(null);
      const name = SIZES[i++];
      const url = `https://i.ytimg.com/vi/${videoId}/${name}.jpg`;
      const img = new Image();
      img.onload = () => {
        // Guard against the legacy 120x90 placeholder served with 200
        if (name === 'maxresdefault' && img.naturalWidth < 200) return tryNext();
        resolve({ name, url, width: img.naturalWidth, height: img.naturalHeight });
      };
      img.onerror = tryNext;
      img.src = url;
    };
    tryNext();
  });
}

Two details worth noting. First, sddefault (640×480) is 4:3 while the rest of the HD ladder is 16:9 — if your UI expects 16:9, you may want to skip it or crop. Second, the placeholder guard: very old videos serve a tiny 120×90 "no thumbnail" image at the maxresdefault path with HTTP 200, so checking naturalWidth is more reliable than status codes alone.

Server-side, the same chain works with HEAD requests, but be polite: these are cheap CDN hits, not API calls, and there's no quota — but hammering them in a tight loop from one IP is still a good way to get throttled.

Why no API key is needed

This surprises people, but the thumbnail CDN is intentionally public. The images are referenced by every embed player on the web; YouTube can't put them behind auth without breaking embeds. The official Data API (thumbnails resource) returns the same URLs — you're just skipping the quota-limited middleman. What the API gives you that raw URLs don't is metadata (which sizes exist), but as shown above, probing is trivial.

WebP variants

Append .webp instead of .jpg and you get WebP versions of the same images:

https://i.ytimg.com/vi/{VIDEO_ID}/maxresdefault.webp

Useful if you care about bytes on the wire. Availability mirrors the JPG ladder.

Wrapping up

The whole system is: extract 11-char ID → walk the size ladder → take the first real hit. No SDK, no key, no proxy server needed — the browser can do it all directly against i.ytimg.com.

If you'd rather not write the fallback chain yourself, 17NAS YouTube Thumbnail Downloader implements exactly this: paste any YouTube link (watch, youtu.be, Shorts, live, embed, mobile) or bare ID, it probes all sizes, auto-picks the best available, and gives you one-click JPG download or WebP in a new tab. Free, no sign-up, no watermark — everything is fetched by your browser straight from YouTube's image servers.

Web Audio APIだけで音声編集アプリを作る：ブラウザ内処理の仕組みを実装レベルで解説

Truman — Thu, 08 Oct 2026 02:47:39 +0000

Web Audio APIだけで音声編集アプリを作る：ブラウザ内処理の仕組みを実装レベルで解説

音声ファイルをサーバにアップロードせず、ブラウザだけでカット・変換・音量調整ができるWebアプリがあります。これを支えているのが Web Audio API です。今回は「ブラウザ内で音声編集が完結する仕組み」を、実装レベルのコードとともに解説します。

1. decodeAudioData：ファイルを AudioBuffer（32bit float PCM）に変換する

Web Audio API の入口は AudioContext と decodeAudioData です。MP3 や WAV といったファイルを、編集可能な PCM データ（AudioBuffer）にデコードします。

const ctx = new AudioContext();
const res = await fetch('voice.mp3');
const arrayBuffer = await res.arrayBuffer();
const audioBuffer = await ctx.decodeAudioData(arrayBuffer);

// audioBuffer.sampleRate        → 44100 など
// audioBuffer.numberOfChannels  → 1（モノラル）or 2（ステレオ）
// audioBuffer.getChannelData(0) → Float32Array（32bit float PCM、-1.0〜1.0）

AudioBuffer の中身は、チャンネルごとの Float32Array です。「編集する」とは、この配列を直接いじることに他なりません。入力フォーマットの差（MP3 / WAV / M4A など）は decodeAudioData が吸収してくれますが、対応コーデックはブラウザ依存です（例：Safari は OGG/Vorbis をデコードできません）。

2. 波形選択とトリミング：秒数をサンプル数に直すだけ

波形上で範囲を選んで切り出す処理は、考え方はシンプルです。秒数をサンプル数に変換し、配列を切り出すだけです。

function trim(buffer, startSec, endSec, ctx) {
  const sr = buffer.sampleRate;
  const start = Math.floor(startSec * sr);
  const length = Math.floor((endSec - startSec) * sr);
  const out = ctx.createBuffer(buffer.numberOfChannels, length, sr);
  for (let ch = 0; ch < buffer.numberOfChannels; ch++) {
    out.getChannelData(ch).set(
      buffer.getChannelData(ch).subarray(start, start + length)
    );
  }
  return out;
}

ミリ秒単位の精密な選択も同じ理屈です。波形の描画自体は getChannelData の値を間引いて canvas にプロットすれば実現できます。

3. 削除時の 4ms クロスフェード：つなぎ目の「プチッ」を消す

区間を削除して前後をつなぐと、波形の段差で「プチッ」というクリックノイズが発生します。これを防ぐ定番の手法が、つなぎ目にごく短いクロスフェードをかけることです。

function spliceWithCrossfade(head, tail, sampleRate) {
  const fadeLen = Math.floor(sampleRate * 0.004); // 4ms
  // head の末尾 fadeLen サンプルを、tail の先頭とミックスする
  for (let ch = 0; ch < head.numberOfChannels; ch++) {
    const h = head.getChannelData(ch);
    const t = tail.getChannelData(ch);
    for (let i = 0; i < fadeLen; i++) {
      const k = i / fadeLen; // 0 → 1
      const idx = h.length - fadeLen + i;
      h[idx] = h[idx] * (1 - k) + t[i] * k;
    }
  }
  // あとは head と tail.slice(fadeLen) を連結する
}

4ms という短さなら音の違和感はほぼなく、段差だけがきれいに消えます。

4. ピーク正規化：ピーク検出 → ゲイン計算

「全体の音量を、最大ピークが -1dBFS になるように揃える」処理です。手順は3ステップです。

全チャンネル・全サンプルを走査し、絶対値の最大（ピーク）を求める
目標値 ÷ ピークでゲインを計算する（-1dBFS ≒ 0.891）
全サンプルにゲインを掛ける

function peakNormalize(buffer, targetDb = -1) {
  let peak = 0;
  for (let ch = 0; ch < buffer.numberOfChannels; ch++) {
    const d = buffer.getChannelData(ch);
    for (let i = 0; i < d.length; i++) {
      const v = Math.abs(d[i]);
      if (v > peak) peak = v;
    }
  }
  const gain = Math.pow(10, targetDb / 20) / peak;
  for (let ch = 0; ch < buffer.numberOfChannels; ch++) {
    const d = buffer.getChannelData(ch);
    for (let i = 0; i < d.length; i++) d[i] *= gain;
  }
}

注意点として、すでに音割れしている（クリッピング済みの）素材はこの処理では直りません。正規化は「小さすぎる音を安全に持ち上げる」ための処理です。

5. エンコード：WAV 16bit 出力と lamejs による MP3 化

編集後の AudioBuffer は float32 のままではファイルに保存できません。WAV なら 16bit PCM に変換してヘッダを付けるだけです。

// Float32（-1.0〜1.0）→ Int16 への変換
function floatTo16BitPCM(view, offset, input) {
  for (let i = 0; i < input.length; i++, offset += 2) {
    const s = Math.max(-1, Math.min(1, input[i]));
    view.setInt16(offset, s < 0 ? s * 0x8000 : s * 0x7FFF, true);
  }
}

MP3 はブラウザ標準 API ではエンコードできないため、LAME の JavaScript 移植版である lamejs を使います。ビットレートは 96〜320kbps の範囲で指定できます。

import { Mp3Encoder } from 'lamejs';
const encoder = new Mp3Encoder(2, 44100, 128); // ch, sampleRate, kbps
// Int16 化したサンプルをブロックごとに入力 → encoder.encodeBuffer()
// 最後に encoder.flush() で残りのデータを吐き出す

実測ではデスクトップ環境で約5倍速（1分の音声を約12秒でエンコード）程度の性能が出ます。すべてブラウザ内（メインスレッド〜Worker）で完結し、サーバ通信はゼロです。

6. ブラウザ差とメモリの現実

実装上ぶつかる壁は主に2つです。

コーデック差：decodeAudioData の対応形式はブラウザ依存です。MP3 / WAV はほぼ共通ですが、OGG は Safari 非対応、Opus の扱いにも差があります。対応入力形式の表は「実際にデコードできるか」の実測で作るのが確実です。
メモリ：PCM は非圧縮なので重いのが現実です。44.1kHz ステレオで1時間分 = 44100 × 2ch × 4byte × 3600秒 ≒ 1.3GB。実用的な設計としては、400MB（約19分）を超えたあたりで警告を出すのが無難です。

7. プライバシー設計：ローカル処理 = アップロードなし

この方式の最大の利点は、音声データがユーザーの PC から一歩も出ないことです。サーバに送らないので通信の待ち時間がなく、サーバ側での保存・漏洩リスクも存在しません。「無料・登録不要」がビジネスとして成立するのも、サーバコストがほぼゼロだからです。

この仕組みをそのまま使った無料ツール例として、17NAS Online Audio Tools があります。登録不要・透かしなしで、ここで解説したトリミングやピーク正規化、MP3/WAV 変換などがブラウザ内だけで動きます。