Base64文字列やバイナリファイルをブラウザ上で瞬時にエンコード・デコード。URLセーフなbase64url、UTF-8、MIME改行、Data URL、破損データのリアルタイム自動修復に対応。
Base64文字列やバイナリファイルをブラウザ上で即座に相互変換。URLセーフ（base64url）、UTF-8マルチバイトUnicode、MIME規格の改行整形、Data URL（Data URI）スキーム生成、不正文字のリアルタイム修復に対応した技術リファレンスです。
0から63までの6ビット整数値に割り当てられた64文字のマッピングテーブル。標準RFC 4648では [A-Za-z0-9+/] を採用し、URLセーフ規格（base64url）では '+' と '/' をそれぞれ '-' と '_' に置換します。
入力バイナリストリームが24ビットの倍数でない場合に末尾へ付与される補完文字。余りバイトが1バイトの場合は '=='、2バイトの場合は '=' を追加します。base64url規格では通常省略されます。
CRLFまたはLF改行を挿入する列文字数の指定。MIME（電子メール）規格では76文字、PEM（証明書・暗号鍵）規格では64文字ごとに改行を挿入し、最新のWeb APIやJSON連携では通常「なし（連続文字列）」を指定します。
平文テキストをシリアライズするバイト符号化規格。UTF-8は日本語・多言語Unicode文字や絵文字を完全に網羅します。ISO-8859-1（Latin-1）およびASCIIは1バイト文字圏に限定されます。
画像、Webフォント、音声、各種文書ファイルをHTMLやCSSファイル内に直接インライン埋め込み可能なMIMEプレフィックス付きURI形式（data:[<mediatype>][;base64],<data>）。
ブラウザ標準の window.btoa() 関数は、Latin-1 の範囲外（コードポイントが255を超える日本語文字や絵文字など）を渡すと InvalidCharacterError 例外を発生させます。日本語を含む最新のUTF-8テキストを安全にBase64化するには、new TextEncoder().encode(str) を用いて文字列を一旦 Uint8Array バイト配列に変換してからBase64へマッピングしてください。
標準のBase64にはプラス記号（+）とスラッシュ（/）が含まれます。これらをHTTPのURLクエリパラメータに直接渡すと、多くのWebサーバーが '+' を半角スペースとしてデコードしてしまいデータが破損します。URLやクエリパラメータを扱う際は、必ず '+' を '-'、'/' を '_' に置換し、末尾のパディング記号（=）を除去する URL-Safe Base64url（RFC 4648 §5）仕様を採用してください。
アセットを Data URL として埋め込むとHTTPラウンドトリップが解消される一方、Base64化によりバイナリサイズは正確に33.33%（3バイトに対して4文字）増大し、ブラウザによる個別キャッシュも効かなくなります。Data URLのインライン埋め込みは4KB未満の極小アイコンやクリティカルSVGに限定し、それ以上のメディアファイルは HTTP/2 や HTTP/3 で配信してブラウザキャッシュを活用することを推奨します。
外部APIやログ出力で末尾のイコール記号（=）が切り捨てられている場合、剰余演算を用いて必要なパディング長を算出できます。文字列長を4で割った余り（stringLength % 4）を計算し、余りが2なら '==' を、余りが3なら '=' を追加します。余りが1の場合は、6ビットでは8ビットの1オクテットを構成できないため、データ自体が破損（不正形式）していると判定できます。
入力文字列にBase64の定義外文字（半角スペース、改行コード、または %2B などのパーセントエンコード文字）が混入しています。「自動クリーン」スイッチを有効にして空白の除去やハイフン／アンダースコアの正規化を行うか、対象データが URL-Safe な base64url 形式でエンコードされていないか確認してください。
文字エンコーディングの不一致が原因です。元データは UTF-8 のマルチバイトバイト列から変換されたにもかかわらず、デコーダー側が ISO-8859-1（Latin-1）として読み込んでいる（またはその逆）状態です。「テキスト文字エンコーディング」セレクターを Latin-1/ASCII から UTF-8 に切り替えることで、本来の日本語・マルチバイト文字を正常に再構築できます。
Base64は6ビット単位で文字を割り当てます。文字列長を4で割った余りが1の場合、末尾に6ビットしか存在せず、最小単位である1バイト（8ビット）の復元すら不可能です。これはネットワーク転送時やコピー＆ペーストの際に文字列が途中で切断されたことを示しています。送信元から完全なペイロードを再取得してください。
Base64は、バイナリデータの3バイト（24ビット）を4つの6ビット値に分割し、それぞれを印字可能なASCII文字4文字に置き換えます。出力される各文字はメモリ上やHTTP通信において8ビット（1バイト）のASCII文字として保持されるため、入力時の24ビットが32ビットのデータへと変換されます。この固定の数学的比率（4/3）により、改行やパディングを除いた純粋なデータサイズが正確に33.33%増大します。
標準のBase64（RFC 4648 §4）は、62番目と63番目の文字に '+' と '/' を使用し、アライメント調整に '=' を用います。しかし、URLクエリ文字列やファイル名において '+' は半角スペースとして扱われ、'/' はパス区切り文字として認識されます。これに対し Base64url（RFC 4648 §5）では、'+' をハイフン（-）に、'/' をアンダースコア（_）に置き換え、さらに末尾の '=' パディングを省略することで、URLエンコードを介さずに安全に送信できる形式に標準化されています。
ブラウザネイティブの btoa() 関数は、各文字のコードポイントが1バイト（0〜255）の範囲に収まるバイナリ文字列専用に策定された古いAPIだからです。現代の日本語や漢字、絵文字などの Unicode 文字は UTF-8 で2〜4バイトを消費するため、コードポイント255を超える文字を渡すと btoa の仕様違反となります。最新のWebフロントエンドでは、Base64変換を行う前に TextEncoder を用いて文字列をUTF-8バイト列へシリアライズする必要があります。
外部ファイルを作成せずにHTMLやCSSでBase64画像を表示するには、適切なメディアタイプ（MIMEタイプ）とBase64識別子を先頭に付与します（書式: data:image/[フォーマット];base64,[データ]）。たとえばPNG画像の場合、data:image/png;base64,iVBORw0KGgo... のような形式になります。この文字列全体をHTMLの <img> タグの src 属性や、CSSの background-image: url(...) プロパティに直接記述することでレンダリングできます。
RFC 7515（JWS）および RFC 4648 §5 で規定されている JSON Web Token（JWT）、OAuthアクセストークン、URLスラッグなどを生成する際には、イコール記号（=）によるパディングを省略することが標準です。パーサー側で文字列長を把握できるため、不足しているビット数は剰余計算（string.length % 4）によって数学的に一意に算出可能であり、パディングを省くことで冗長性を排除しURLの文字数を節約できます。
JSONデータを解析し、洗練されたTypeScriptのinterfaceやtypeエイリアスへ変換。ネストされたオブジェクトや配列の型推論に対応。
生のJSONデータからTypeScript Zodスキーマ、型定義、ネストされたバリデーションルールをブラウザ上で自動推論・生成します。
JSON構造を高パフォーマンスなTypeBoxのType.Object定義に変換。Fastify、Ajv、TypeScriptのランタイム型検証に即座に利用可能です。
JSONデータをv.object、v.string、v.numberなどの軽量かつツリーシェイカブルなValibotスキーマ定義に高速変換します。
JSONデータからPythonのPydantic v2 BaseModel、TypedDict、@dataclassクラスコードを自動推導。型アノテーションやフィールド別名エイリアスを完備します。
JSONデータをGolangの慣用的なStruct構造体定義へ瞬時に変換します。ネストした型の分離定義、json/yaml/gormタグの自動付与、omitempty制御に対応。