> base64 編碼器 | text | file <

將您的文字輸入或貼上至上方 輸入 區域。自動編碼預設開啟 — Base64 結果會在您輸入時即時顯示於 輸出 區域。點擊 [ENCODE] 或按 Ctrl/Cmd + Enter 可手動觸發編碼。依據 Base64 的使用場景切換 --url-safe 或 --no-padding（JWT、OAuth、URL → 兩者皆開啟）。全部於本機瀏覽器執行：不上傳、無記錄、無與您輸入內容關聯的網路請求。

點擊輸入區域下方的 [upload file] 按鈕並選擇最大 100 MB 的檔案。編碼器以 FileReader.readAsArrayBuffer 讀取檔案，透過 btoa 以 32 KB 區塊串流處理位元組（避免大檔案使瀏覽器當掉），並將完整 Base64 寫入輸出區。更大檔案請使用命令列編碼器：base64 < input.bin > output.txt（macOS/Linux），或 PowerShell：[Convert]::ToBase64String([IO.File]::ReadAllBytes('input.bin'))。

若您希望將 Base64 格式化為 Data URI（例如 data:image/png;base64,...），請於輸出前加上 MIME 類型和 ;base64,，或使用我們專用的 圖片轉 Base64 工具，可直接輸出 PNG、JPG、GIF、WebP 與 SVG 的 Data URI 供貼上。

三者皆定義於 RFC 4648：

• 標準 Base64（§4）使用字母表 A-Z a-z 0-9 + / 並以 = 填補。輸出長度必為 4 的倍數。可安全用於 MIME、HTTP Basic 認證與 JSON 字串值。

• URL 安全 Base64（§5）以 - 取代 +，以 _ 取代 /。當 Base64 放置於 URL 路徑、查詢參數、檔名或 JWT 分段時必須使用 — 否則標準的 +/ 字元需要額外的百分號編碼。

• 無填補（§4 與 §5 皆可，base64url 無填補版）移除末尾 =。長度不再是 4 的倍數，但解碼器可從長度對 4 取餘數來推算原始長度。用於 JWT（依 RFC 7515 的 base64url）、WebAuthn 及部分 CBOR/COSE 實作。

解碼器須明確告知要處理的變體 — 我們的 Base64 解碼器 會自動偵測全部三種。

所有主流語言與執行環境皆內建 Base64 編碼。可直接複製貼上的片段：

JavaScript（瀏覽器）：
btoa('Hello') // SGVsbG8=
// UTF-8 處理:
btoa(String.fromCharCode(...new TextEncoder().encode(s))) // UTF-8 safe

Node.js：
Buffer.from('Hello', 'utf-8').toString('base64') // SGVsbG8=
Buffer.from(bytes).toString('base64url') // URL-safe, no pad

Python：
import base64
base64.b64encode(b'Hello').decode() # SGVsbG8=
base64.urlsafe_b64encode(b'Hello').decode().rstrip('=') # URL-safe no-pad

PHP：base64_encode('Hello')
Ruby：Base64.strict_encode64('Hello') / Base64.urlsafe_encode64('Hello')
Go：base64.StdEncoding.EncodeToString([]byte("Hello")) / base64.URLEncoding.EncodeToString(...) / base64.RawURLEncoding.EncodeToString(...)（無填補）
Java：Base64.getEncoder().encodeToString("Hello".getBytes(StandardCharsets.UTF_8))
C#：Convert.ToBase64String(Encoding.UTF8.GetBytes("Hello"))
Rust：base64::engine::general_purpose::STANDARD.encode("Hello")

Shell（macOS/Linux）：echo -n 'Hello' | base64 → SGVsbG8=。Linux 上使用 base64 -w 0 可抑制 76 欄折行。

Base64 輸出約比輸入大 33%：每 3 個輸入位元組變成 4 個輸出字元。確切公式：含填補為 ceil(n / 3) × 4，不含填補為 ceil(n × 4 / 3)。若在 76 欄（MIME）或 64 欄（PEM）折行還會多出幾位元組額外負擔。

範例：
• 1 KB 二進位 → 約 1.37 KB Base64
• 100 KB 圖片 → 約 137 KB Data URI
• 1 MB PDF → JSON 中約 1.37 MB Base64

何時應避免 Base64：
• 大檔案傳輸：將 10 MB 圖片以 Base64 嵌入 HTML 會變成 13.7 MB 已解析文字，阻塞主執行緒，且無法獨立快取。建議使用 <img src="/assets/photo.png">。
• 效能敏感的 API：JSON 中 500 KB 的 Base64 payload 解析速度比同等二進位端點慢約 2-3 倍。
• 作為安全措施：Base64 不是加密 — 任何人都能解碼。機密性請使用 AES-GCM 等方案。
• 資料庫 BLOB：請以 BLOB/BYTEA 儲存原始位元組，而非 Base64 文字，可節省 33% 儲存並避免編碼/解碼往返。

JWT（RFC 7515）與 OAuth PKCE（RFC 7636）皆使用無填補的 URL 安全 Base64，通常稱為 base64url。於本工具產生：同時啟用 --url-safe 與 --no-padding 核取方塊，然後編碼您的文字。

程式化等價寫法：
• JavaScript：btoa(s).replace(/\+/g, '-').replace(/\//g, '_').replace(/=+$/, '')
• Node.js：Buffer.from(s).toString('base64url')
• Python：base64.urlsafe_b64encode(s.encode()).decode().rstrip('=')
• Go：base64.RawURLEncoding.EncodeToString([]byte(s))
• Java：Base64.getUrlEncoder().withoutPadding().encodeToString(bytes)

常見需要 base64url 的 JWT 欄位：以點號分隔的三段（header、payload、signature）、OAuth PKCE 的 code_verifier/code_challenge、WebAuthn challenge、Web Push 的 p256dh/auth 金鑰，以及 Google 的 Request.state 參數。

常見的錯誤是以標準 Base64（+/）傳送 JWT — API 會視為格式錯誤而拒絕，因為 + 在傳輸中會被 URL 解碼成空格。

可以，但有一個注意事項。本編碼器產生 Data URI 的 Base64 部分 — 也就是 ;base64, 之後的部分。要構建完整 Data URI，請前置：

data:<mime-type>;base64,<encoded-output>

常見 MIME 類型：
• data:image/png;base64,... — PNG 圖片
• data:image/jpeg;base64,... — JPEG 圖片
• data:image/svg+xml;base64,... — SVG（或使用 data:image/svg+xml;utf8, 不經 Base64 — 通常更小）
• data:application/pdf;base64,... — PDF 檔案
• data:application/font-woff2;base64,... — 字型嵌入
• data:text/plain;charset=utf-8;base64,... — 以 Base64 包裹的文字

圖片與 SVG 請使用 圖片轉 Base64 工具，會輸出完整 Data URI，可直接貼入 CSS 的 background-image、內嵌 <img src="..."> 或 <object data="..."> 標籤。

大小警告：超過 20-30 KB 的 Data URI 會傷害 LCP（Largest Contentful Paint），因為瀏覽器無法預先載入 — 請保持內嵌 Base64 圖片小型化，較大資源建議使用一般 <img> 搭配 loading="lazy"。

是的 — 任何資料都不會離開您的瀏覽器。 編碼器完全於 JavaScript 中執行，使用原生 btoa()、TextEncoder 與 FileReader API。不會對輸入內容發出網路呼叫，無遙測、無記錄，亦無對您所編碼內容的第三方分析。您可於編碼時開啟 DevTools 網路面板觀察到零相關請求。

但 Base64 不是加密 — 它是可逆編碼，任何拿到輸出的人都能解碼。因此：
• 不要將正式環境密鑰貼入聊天、截圖或日誌，即使是編碼過的形式。
• HTTP Basic 認證中的 Base64 Authorization: Basic 標頭只有在 TLS（HTTPS）下才安全。在明文 HTTP 上極易被嗅探。
• 真正的機密性請使用 AES-GCM、age、sops 或 KMS — 再於需要傳輸時對密文進行 Base64 編碼。

對於嚴格的資料外洩管控原則，請將此頁離線儲存（Cmd/Ctrl + S）。載入一次後編碼器即可完全氣隙運作，無伺服器相依。

編碼器透過檔案處理器中的硬性上限支援最大 100 MB 的檔案 — 足以處理大多數圖片、PDF、ZIP 壓縮檔甚至短影片。效能目標：

• < 1 MB：編碼於 50 ms 內完成，UI 不凍結。
• 1 – 10 MB：依 CPU 約 100-500 ms。因採 32 KB 區塊編碼，瀏覽器保持回應。
• 10 – 100 MB：2-15 秒。貼上/捲動如此大的 Base64 字串時輸出文字區可能略有延遲。必要時可考慮從 DevTools 將輸出下載為 .txt 檔。
• > 100 MB：被阻擋 — 瀏覽器記憶體負擔（輸入位元組 + 二進位字串 + Base64 字串 ≈ 檔案大小的 3-4 倍）有使分頁當機的風險。請使用：

# macOS / Linux
base64 -i huge.bin -o huge.b64

# Windows PowerShell
$bytes = [IO.File]::ReadAllBytes('huge.bin')
[IO.File]::WriteAllText('huge.b64', [Convert]::ToBase64String($bytes))

串流/多 GB 工作流程可參考 大型檔案的 Base64 編碼，介紹於 Node.js/Python 中以分塊方式處理、避免將整個檔案載入記憶體的做法。

本編碼器使用 UTF-8，也就是現代網頁、JSON、Linux、macOS 及幾乎所有程式語言預設使用的編碼。底層將文字透過 new TextEncoder().encode(input) 轉為 UTF-8 位元組，然後才進行 Base64 編碼。

為何重要：較舊的 JavaScript btoa() 函式僅處理 Latin-1，遇到 é、中 或 😀 等字元會抛出 InvalidCharacterError。我們的包裝層會為您處理 UTF-8 轉換，因此 emoji、中文、日文、韓文、阿拉伯文、西里爾文及任意 Unicode 碼位都能正確編碼。

若您需要不同的編碼：
• UTF-16 LE（Windows 原生）：罕見 — 通常代表舊系統互通。仍建議使用 new TextEncoder({ fatal: true }).encode(s)，並在上游轉換。
• ISO-8859-1 / Latin-1：於編碼前手動將碼位 0-255 對應到位元組。
• GB18030、Shift_JIS、EUC-KR：於 Node.js 使用 iconv-lite 等函式庫先轉碼。

有一個微妙的陷阱：若您的來源資料已是非 UTF-8 編碼（例如讀取舊 MySQL dump），需先以正確的編解碼器解碼，再重新編碼為 UTF-8 後進行 Base64 — 否則解碼後的 Base64 會保留亂碼。