三タブの用途
本ツールは，「Base64 相互変換」「テキスト → Base64」「Base64 → テキスト」という3つの専用タブを備え，データの性質や変換の目的に応じた処理を提供するWebアプリケーションです．一番目の「Base64 相互変換」タブでは，すでにエンコード済みのBase64文字列を入力値として受け取り，標準Base64形式とURL-Safe Base64形式の間で直接的な表記変換を行います．
この機能はテキストエンコーディング（UTF-8）の処理を中間に挟まないため，元のデータがテキストではなく画像や音声などのバイナリ由来のBase64文字列であっても，指定された記号の置換のみを実行します．二番目の「テキスト → Base64」タブは，入力エリアに打ち込まれたプレーンテキスト（UTF-8）から，標準形式とURL-Safe形式の2種類のBase64文字列を同時に生成する用途に用います．
これは，日本語などのマルチバイト文字を含むテキストデータをWebアプリケーションのURLパラメータやルーティングに組み込む際，表記を整える一つの方法です．三番目の「Base64 → テキスト」タブでは，選択した形式（標準またはURL-Safe）のBase64文字列を解釈し，元のUTF-8テキストにデコードして画面に出力します．
ここでは，入力データが正しいBase64形式であるかの判定に加え，デコード結果がUTF-8として正当なバイト列であるかの厳密な検証が行われます．本ツールのこれらすべての変換処理と文字列検証は，JavaScriptを用いてブラウザ内のメモリ上で実行されるため，外部のサーバー側プログラムにデータを渡す仕組みは含まれていません．
alphabetとpadding
URLセーフBase64（URL-Safe Base64）は，標準的なBase64（RFC 4648に基づく）で用いられる特定のアルファベット記号を，WebブラウザのアドレスバーやURLのパス，クエリパラメータにおいて問題を引き起こしにくい別の記号に置き換えた仕様です．
標準Base64の文字セットには +（プラス）と /（スラッシュ）が含まれていますが，これらはHTTPリクエストのURL構造において，空白文字のエンコード表現やディレクトリ階層の区切り文字としての特別な意味を持っています．そのため，標準Base64のままURLパラメータに含めると，サーバー側で意図しないパース処理が行われ，データの欠落や構文エラーといった不具合が生じる原因となります．
この問題を防ぐため，本ツールではエンコード時に + を -（ハイフン）に，/ を _（アンダースコア）に置き換える処理を正規表現によって実行します．さらに，標準Base64のデータ末尾に付加されることが多い =（パディング文字）についても，URL内で特別な意味を持つ場合があるため，.replace(/=+$/, "") によってすべて削除されます．
逆に，URL-Safe Base64の文字列を標準Base64の形式に戻す処理においては，まず - を + に，_ を / に一括で置換し直します．その後，文字列の長さを文字単位（コードユニット）で取得し，4で割った余り（length % 4）を計算します．
この余りが2の場合は不足している == を，余りが3の場合は = を文字列の末尾に連結することで，標準的なBase64デコーダが要求する4文字単位のパディングブロックを復元し，形式を整える処理を行っています．
直接変換とbyte
「Base64 相互変換」タブで提供される表記の直接変換機能は，UTF-8テキストへのデコードや再エンコードを一切経由せず，Base64の文字列表記規則のみを高速に相互変換する仕組みです．本処理ではまずトリミング前の生入力に対して入力長制限が評価され，Base64入力は前後の空白を含めて最大4,194,304文字（UTF-16コード単位）までに制限されており，これを超過したデータは切り捨て処理を行わずにエラーとして即座に拒否されます．
サイズ上限を満たした場合，文字列の外側に位置する前後の空白文字のみが除去され，文字列内部に含まれる空白や改行，タブ文字は不正な文字として厳格に検出・拒否されます．構文検証では，選択されたモードに応じて標準アルファベット（A-Z，a-z，0-9，+，/）またはURL-safeアルファベット（-，_）のみが許可され，他方の文字セットの混入は一切許容されません．
パディングに関しては，末尾の正当なパディング文字（=）の有無を問わず，正しい構造であればパディング付き・パディング省略（未付与）のいずれの形式も受け付けます．ただし，Base64長が4で割った余りが1となる不正な長さ，途中へのパディング混入，過剰なパディング付与，およびパディング直前の境界ブロックにおける未使用末尾ビット（ゼロパディング領域）に非ゼロの値が含まれるデータは，本ツールの厳格な検証ポリシーに基づき不整合として拒否されます（RFC 4648ではデコーダが非ゼロの余剰ビットを拒否してもよいと規定されています）．
入力値が不正となった場合は直前の変換結果を残さず出力がクリアされます．変換が成立した場合，標準Base64形式の出力にはパディングが付与され，URL-safe形式の出力はパディングなしの形式として生成されます．なお，直接変換の方向モードを切り替えた際は入力値と出力値が共にクリアされます．
バイト列の整合性が完全に保持されるため，画像やアーカイブなどのバイナリデータに対する表記形式の変更に適しています．
UTF8テキストの生成
「テキスト → Base64」タブにおけるエンコード処理では，プレーンテキストをUTF-8バイト列へ正確に変換した上でBase64文字列を生成します．入力データに対しては事前の文字数制限が存在し，トリミング前の状態で最大1,048,576個のUTF-16コード単位までに制限されています．
この制限はバイト数や書記素クラスター数（見た目の文字数）ではなくJavaScript文字列のUTF-16コード単位で測定されるため，絵文字や一部の漢字などのサロゲートペアで表現される補助文字は1文字で2単位として加算されます．制限を超過した入力は末尾を自動で切り捨てることなく全体がエラーとして拒否されます．
なお，この入力上限値は環境依存の処理能力やブラウザの快適な動作を普遍的に保証するものではありません．検証段階では孤立したサロゲートなどの不対UTF-16サロゲートが含まれていないかが精査され，不正なシーケンスは直ちに検出・拒否されます．正当なテキストは TextEncoder によりUTF-8の Uint8Array バイト配列へと変換されます．
このバイト配列からバイナリ文字列を構築する際，配列全体を一度に引数展開（スプレッド構文など）すると引数上限によるスタックオーバーフローが発生するリスクがあるため，本処理では最大8192バイトのチャンク（まとまり）に分割して順次ループ処理を行い，各チャンクに String.fromCharCode を適用して安全に文字列を連結構築します．
生成されたバイナリ文字列は window.btoa に渡され，パディングが付与された標準Base64文字列が算出されます．さらにURL-safe形式（+ を -，/ を _ に置換し末尾の = を除いたパディングなし形式）も同時に導出され，画面上には標準とURL-safeの双方の出力エリアへ同時に表示されます．
各エリアのクリップボードへのコピー操作では，非同期のClipboard API呼び出しが完了（await）したことを確認した後にのみ成功表示が行われ，権限拒否や失敗時には手動での選択・コピーが促されます．
形式とUTF8エラー
「Base64 → テキスト」タブのデコード機能では，Base64文字列から元のUTF-8テキストを厳格に復元します．入力文字列にはトリミング前の制限として最大4,194,304文字（UTF-16コード単位）の上限が設けられており，前後の空白を含めて超過した場合は切り捨てずに入力エラーとなります．
外側の余白のみがトリミングされ，内部に混入した空白文字や改行は不正構文として拒否されます．ユーザーは標準Base64かURL-safe Base64かを切り替えて指定でき，このモード切替時は入力欄の文字列を保持したまま再検証と再計算が実行されます．構文検査では選択された形式の文字セット（標準またはURL-safe）のみが許可され，他方の記号混入は排除されます．
末尾のパディング（=）は正当な構造であれば付与・省略の双方が許容されますが，長さが4で割って余り1となる形式，途中パディング，過剰パディング，および末尾境界ブロックの未使用ビットに非ゼロ値が残存するデータは厳格に拒否され，無効な入力に対して直前の計算結果が保持されることはありません．
URL-safe形式の場合は記号置換とパディング補完を経てバイナリ配列（Uint8Array）へと変換されます．続くテキスト復元では new TextDecoder('utf-8', { fatal: true, ignoreBOM: true }) が使用され，先頭のBOM（U+FEFF）を維持するとともに，元から含まれていた正当な置換文字（U+FFFD）はそのまま保持されます．
この fatal: true 指定により，不正なバイト列に対して置換文字を勝手に補填して文字化け表示を許容することはなく，画像や圧縮ファイルなどの非UTF-8バイナリデータが渡された場合は例外を発生させてデコードを停止し，エラー通知を行います．そのような純粋なバイナリデータに対して表記のみを変更したい場合は，テキストデコードではなく「Base64 相互変換」タブの直接変換機能を利用します．
暗号・認証・JWTとの線引き
Base64およびURL-Safe Base64という技術は，バイナリデータやマルチバイト文字の集合をASCII文字列の限られた文字セットの範囲内で表現するためのデータ形式の変換（エンコード）手法にすぎず，データを秘匿するための暗号化技術やセキュリティ対策ではありません．
URLパラメータとしてデータを引き渡す際，予約された記号との競合による構文エラーを防ぐという目的には合致しますが，変換された文字列自体は所定の逆変換手順を踏めば誰でも簡単に元のデータへデコードできる状態にあります．本ツールの実装においても，テキストデータを暗号化・復号するアルゴリズムや，データの改ざんを防ぐためのハッシュを用いた電子署名の付与機能，さらにはJSON Web Token (JWT) のような認証トークンの有効性を検証する機能は一切備えていません．
したがって，パスワードやセッションキー，個人識別情報（PII）などの第三者に知られてはならない秘匿すべきデータを，本ツールでURL-Safe Base64に変換しただけでURLパラメータに付与するシステム設計は極めて不適切です．データの秘匿性や完全性の証明が必要な場合は，バックエンドのシステムや専用の暗号化ライブラリを用いて事前に適切な暗号化処理と署名を行い，その結果として得られたバイト列に対してのみ，表記規則を合わせる目的でBase64変換を適用するなどの明確な線引きが求められます．
また，データ圧縮機能やファイルI/Oにも対応していないため，仕様を理解した上での運用が必要です．