Web Crypto API を使って、入力したテキストの SHA-256 と SHA-1 をブラウザ内で計算します。入力は送信されません。ハッシュは暗号化ではありません — 元に戻す鍵が無いのではなく、そもそも戻すための情報が捨てられている関数です。ただしこれは「安全である」という意味ではありません — 入力の候補が限られていれば、片端から計算して突き合わせるだけで元の値は判明します。

ケース	何が起きるか	どうする
パスワードの保存に SHA-256 を使ってしまう	SHA-256 は「速いこと」を目的に設計された関数です。ファイルの整合性を確かめるには速いほど良いのですが、パスワードの保存に使うと、その速さがそのまま攻撃者の武器になります — 現代の GPU は 1 秒間に数十億回の SHA-256 を計算できるので、英数字 8 文字のパスワードは総当たりで数時間以内に破られます。ソルトを付けても事情は変わりません — ソルトはレインボーテーブルを無効化し、同じパスワードが同じハッシュになるのを防ぐだけで、1 件ずつの総当たりの速さには一切影響しません。	パスワードには `bcrypt` / `scrypt` / `Argon2id` を使ってください。これらは意図的に遅く、かつ大量のメモリを要求するように設計されています — メモリを食うという性質が重要で、GPU は演算器の数に対してメモリが少ないため、並列化の利点を消せます。「SHA-256 にソルトを足して 1 万回繰り返す」という自作の設計はやめてください — 発想は正しいのですが、それは `PBKDF2` として既に標準化されており、自作の実装は必ずどこかで間違えます。2026 年時点の推奨は `Argon2id`、言語やフレームワークに無ければ `bcrypt` です。
同じ文字列なのに他のツールと値が違う	ハッシュ関数が受け取るのはバイト列であって、文字ではありません。したがって同じに見えるテキストでも、バイト列が 1 バイトでも違えば結果は完全に別物になります。実務で食い違う原因はほぼこの 4 つです — 末尾の改行、改行コードが LF か CRLF か、BOM の有無、文字コードが UTF-8 か Shift-JIS か。とくに典型的なのがシェルで、`echo "abc" \| sha256sum` は改行を含む 4 バイトのハッシュを返します — `abc` の 3 バイトではありません。	シェルでは `printf %s abc \| sha256sum` を使ってください — 余計なバイトが付きません (`echo -n` は環境によって挙動が違うので避けます)。食い違ったときは、まず両側のバイト数を数えてください — `wc -c` や `xxd` で 1 バイトの差はすぐ見つかります。API の署名検証で合わないという場合も、原因はほぼ同じです — 署名対象の文字列を組み立てる順序、区切り文字、末尾の改行、そしてJSON をシリアライズし直したことでキー順や空白が変わっていないかを確認してください。「同じはず」ではなく、実際のバイト列を突き合わせるのが唯一の解決法です。
SHA-1 をそのまま使い続けている	SHA-1 の衝突は理論上の話ではありません — 2017 年に Google と CWI が内容の違う 2 つの PDF が同じ SHA-1 になる実例を公開しました (SHAttered)。2020 年には選択接頭辞衝突が現実的なコストで可能になり、これは「任意の 2 つの文書を、それぞれ好きな内容にしたまま衝突させられる」という、はるかに強い攻撃です。Git がいまも SHA-1 を使っているのは、「衝突を作れる」ことと「Git を攻撃できる」ことが別問題だからで、SHA-1 が安全だからではありません。	新規に作るものはすべて SHA-256 以上にしてください。既存の SHA-1 については、用途で判断してください — 改ざん検知・署名・証明書に使っているなら移行が必要ですが、ETag・キャッシュキー・シャーディングのような「衝突しても困らない」用途なら急ぐ理由はありません。この区別が重要で、すべての SHA-1 を一律に置き換えようとすると、本当に危険な箇所に手が回らなくなります。判断の基準は「攻撃者が意図的に衝突させたとき、何か得をするか」の一点です — 得をしないなら放置してよく、得をするなら最優先で直してください。

「ハッシュ化したから匿名化した」という扱いは成立しません。メールアドレスや電話番号の SHA-256 を個人情報ではないものとして共有するのは危険です — 電話番号は候補が有限 (日本の携帯なら 10 億通り足らず) なので、全部計算して突き合わせれば数分で元に戻せます。メールアドレスも、既知のアドレス一覧と照合すれば同じことです。これは広告業界で実際に問題になった経路で、ハッシュ化は「入力の候補が事実上無限にある」場合にしか匿名化になりません。どうしても照合用の識別子が必要なら、秘密の鍵を混ぜた HMAC を使ってください — 鍵を知らない側は総当たりができなくなります (ただし鍵の管理という別の責任が発生します)。ハッシュを ID として公開する設計を採る前に、「その入力空間を全部計算するのに何時間かかるか」を実際に見積もってください。

📖 使い方

1

ハッシュ化するテキストを入力

入力欄にハッシュ値を知りたいテキストやパスワードを入力します。入力と同時に SHA-256 と SHA-1 の値がリアルタイムで計算されます。
2

ハッシュ値を確認

SHA-256 (256 ビット / 64 文字の16進数) と SHA-1 (160 ビット / 40 文字の16進数) が表示されます。用途に応じて適切なアルゴリズムを選んでください。
3

コピーして利用

各ハッシュ値右上の「コピー」ボタンでクリップボードにコピーできます。ファイル整合性チェック・API 署名の検証・設定値との照合などに活用できます。

❓ よくある質問

SHA-256 と SHA-1 はどちらを使えばよいですか?

セキュリティが重要な用途には SHA-256 を使用してください。SHA-1 は衝突攻撃に対する脆弱性が発見されているため、新しいシステムでは SHA-256 以上を推奨します。

ハッシュ値は一方向ですか?

はい。ハッシュ関数は一方向で、ハッシュ値から元のテキストを復元することは計算上不可能です。ただし、短いテキストはレインボーテーブルで逆引きできる場合があるため注意してください。

入力データはサーバーに送信されますか?

送信されません。ハッシュ計算は Web Crypto API を使ってブラウザ内で完結しています。入力したテキストやパスワードはサーバーには送信されません。

🐛 このツールで問題が発生しましたか？

完全無料・登録不要。再現手順だけでも結構です。届いたご報告は運営者に直接届き、修正の参考にします。

テキストハッシュ計算（SHA-256・SHA-1）

他のオンラインツール

関連記事

📖 つまずきやすいポイント

📖 使い方

❓ よくある質問

ご報告ありがとうございます！