Skip to content

URLエンコーダー&デコーダー — URL構造パーサー内蔵

URLを貼り付けるだけで即座にエンコード・デコード。内蔵URLパーサーがプロトコル・ホスト・パス・クエリパラメータを編集可能なフィールドに分解。encodeURIとencodeURIComponentの2モード対応。完全ブラウザ動作でデータ送信なし。

トラッキングなし ブラウザで動作 無料
デコード済み
エンコード済み
RFC 3986準拠性、encodeURI/encodeURIComponentの正確性、UTF-8エンコードの正確性について審査済み — Go Toolsエンジニアリングチーム · Apr 7, 2026

URLエンコード(パーセントエンコード)とは?

URLエンコード(正式にはパーセントエンコード)は、RFC 3986で定義されたURI(Uniform Resource Identifier)内で許可されていない文字や特別な意味を持つ文字を表現するためのメカニズムです。安全でない各バイトをパーセント記号(%)に続く2桁の16進数に変換します——例えば、スペースは%20に、アンパサンドは%26に、中国語文字の「中」は%E4%B8%AD(3つのUTF-8バイトがそれぞれパーセントエンコード)になります。

URLにはASCII文字セットの限られた文字のみ含めることができます。英字、数字、少数の記号(- _ . ~)は「非予約」とされ、そのまま使用できます。その他すべての文字——スペース、句読点、Unicode全体——は、URL内で安全に転送するためにパーセントエンコードが必要です。?、&、=、#などの予約文字はURL構文で構造的区切り文字として機能するため、区切り文字としてではなくリテラルデータとして使用する場合もエンコードが必要です。

パーセントエンコードはWeb全体で不可欠です:ブラウザはフォーム送信をエンコードし、APIはエンコードされたクエリパラメータを必要とし、OAuthフローは正しくエンコードされたリダイレクトURIに依存し、国際化ドメイン名は非ASCII文字のエンコードに依存しています。エンコードの誤りはリンク切れ、セキュリティ脆弱性(オープンリダイレクト攻撃など)、データ破損の原因となります。

このツールはencodeURIとencodeURIComponentの両モード、内蔵URL構造解析器、リアルタイム変換、二重エンコード検出を提供し、すべてブラウザ内でプライベートに動作します。

URLエンコードは他のWeb開発ツールと組み合わせて使用されることがよくあります。JWTトークンやAPIペイロードに埋め込むためにURLをBase64エンコードしたり、URL文字列を含むJSONデータをフォーマットして構造を確認したりする場面があります。

// Encode a query parameter value
const param = encodeURIComponent('hello world & goodbye');
console.log(param); // → 'hello%20world%20%26%20goodbye'

// Encode a full URL (preserves structure)
const url = encodeURI('https://example.com/path name?q=hello world');
console.log(url); // → 'https://example.com/path%20name?q=hello%20world'

// Decode a percent-encoded string
const decoded = decodeURIComponent('hello%20world%20%26%20goodbye');
console.log(decoded); // → 'hello world & goodbye'

// Build a URL with encoded parameters
const base = 'https://api.example.com/search';
const query = `?q=${encodeURIComponent('你好')}&lang=zh`;
console.log(base + query); // → 'https://api.example.com/search?q=%E4%BD%A0%E5%A5%BD&lang=zh'

主な機能

デュアルエンコードモード

encodeURI(URL構造を保持)とencodeURIComponent(パラメータ値用にすべてをエンコード)を切り替え、用途に正確に合わせます。

内蔵URL解析器

任意のURLをプロトコル、ホスト、ポート、パス、クエリパラメータ、フラグメントに自動分解——各フィールドは編集可能で、新しいURLに再構築できます。

リアルタイム変換

入力と同時にエンコード・デコードが即座に行われます——ボタンをクリックする必要はなく、キーストロークごとにもう一方のエリアに結果が表示されます。

100%ブラウザベース

すべての処理はネイティブJavaScript APIを使用してブラウザ内でローカルに行われます。データがデバイスの外に出ることはありません——サーバーへのアップロードもトラッキングもありません。

完全なUTF-8サポート

適切なUTF-8バイトエンコード・デコードにより、中国語、日本語、韓国語、アラビア語、絵文字、その他のUnicodeテキストを正しく処理します。

二重エンコード検出

%2520(パーセントエンコードされた%20)などの二重エンコード問題を自動検出して警告し、最も一般的なURLエンコードミスの回避を支援します。

使用例

文字化けURLのデコード

https%3A%2F%2Fexample.com%2Fsearch%3Fq%3Dhello%20world%26lang%3Den
https://example.com/search?q=hello world&lang=en

完全にパーセントエンコードされたURLを人間が読める形式にデコードし、元のクエリパラメータと構造を復元します

中国語文字

https://example.com/search?q=你好世界
https://example.com/search?q=%E4%BD%A0%E5%A5%BD%E4%B8%96%E7%95%8C

中国語文字がUTF-8バイトシーケンスに変換され、パーセントエンコードされます

クエリパラメータ

https://example.com/api?name=John Doe&role=admin&lang=en&sort=date desc
https://example.com/api?name=John%20Doe&role=admin&lang=en&sort=date%20desc

クエリパラメータ値のスペースや特殊文字がパーセントエンコードされ、URL構造は保持されます

完全なURL

https://user:pass@example.com:8080/path/to/page?key=value&arr[]=1#section-2
https://user:pass@example.com:8080/path/to/page?key=value&arr%5B%5D=1#section-2

認証情報、ポート、パス、角括弧付きクエリパラメータ、フラグメント識別子を含む完全なURL

OAuthリダイレクトURI

https://auth.example.com/authorize?redirect_uri=https://myapp.com/callback?code=abc&state=xyz
https://auth.example.com/authorize?redirect_uri=https%3A%2F%2Fmyapp.com%2Fcallback%3Fcode%3Dabc%26state%3Dxyz

redirect_uriの値自体が完全なURLを含んでおり、その特殊文字が外側のURLの一部として解釈されないようにエンコードする必要があります

使い方

  1. 1

    URLまたはエンコード文字列を入力

    デコードエリアにURLを貼り付けてエンコードするか、エンコードエリアにパーセントエンコードされた文字列を貼り付けてデコードします。用途に応じてencodeURIまたはencodeURIComponentモードを選択してください。

  2. 2

    結果と解析構造を確認

    入力に合わせてもう一方のエリアが即座に更新されます。URL解析器がURLをプロトコル、ホスト、ポート、パス、クエリパラメータ、フラグメントに分解します——すべて編集可能です。

  3. 3

    コピーまたは再構築

    コピーをクリックしてエンコードまたはデコード結果をコピーします。個々のURLコンポーネントを編集し、再構築をクリックして変更した部分から新しいURLを構築できます。

よくあるエラー

二重エンコード(%20の代わりに%2520)

二重エンコードは、既にエンコードされたURLが再度エンコードされた場合に発生します。%20の%が%25にエンコードされ、%20が%2520になります。サーバーがスペースではなくリテラルの%20文字列を見るため、URLが壊れます。

✗ 誤り
https://example.com/path%2520with%2520spaces
✓ 正しい
https://example.com/path%20with%20spaces

パスセグメントでスペースが+にエンコードされる

+文字はapplication/x-www-form-urlencoded形式(HTMLフォームのクエリ文字列)でのみスペースを表します。URLパスセグメントでは、+はスペースではなくリテラルのプラス記号として解釈されます。パスセグメントのスペースには常に%20を使用してください。

✗ 誤り
https://example.com/my+file+name.pdf
✓ 正しい
https://example.com/my%20file%20name.pdf

クエリパラメータ値にencodeURIを使用

encodeURI()は&、=やその他の予約文字をエンコードしないため、これらの文字を含むパラメータ値に使用するとクエリ文字列構造が壊れます。

✗ 誤り
encodeURI('key=value&more')  → 'key=value&more' (& not encoded!)
✓ 正しい
encodeURIComponent('key=value&more')  → 'key%3Dvalue%26more'

非UTF-8エンコーディングの想定

一部のレガシーシステムはURLパラメータにLatin-1やShift-JISなどのエンコーディングを使用しています。現代の標準ではUTF-8が必要です。Shift-JISでエンコードされたパラメータをUTF-8デコーダーでデコードすると文字化けします。

✗ 誤り
Decoding %82%B1%82%F1 as UTF-8 (this is Shift-JIS for こん)
✓ 正しい
Using UTF-8: %E3%81%93%E3%82%93 correctly decodes to こん

コンテキストなしの相対パスのエンコード

encodeURIComponentで../images/photo.jpgのような相対パスをエンコードすると、スラッシュやドットがパーセントエンコードされ、パス構造が壊れます。encodeURI()を使用するか、個々のパスセグメントのみをエンコードしてください。

✗ 誤り
encodeURIComponent('../images/photo.jpg')  → '..%2Fimages%2Fphoto.jpg'
✓ 正しい
Encode each segment: '../images/' + encodeURIComponent('my photo.jpg')

一般的なユースケース

文字化けURLのデバッグ
サーバーログ、エラーメッセージ、ブラウザ開発者ツールからのパーセントエンコードされたURLをデコードし、元の人間が読めるテキストを確認します。
API開発
REST APIコールのクエリパラメータ値をエンコードし、&、=、スペースなどの特殊文字がリクエストURLを壊さないようにします。
OAuthフロー設定
OAuth認可URLでredirect_uriやその他のURLパラメータを正しくエンコードし、認証失敗を防止します。
国際化URL
中国語、日本語、韓国語、アラビア語などの非ASCII文字を含むURLをエンコード・デコードし、国際化Webアプリケーションに対応します。
マーケティングリンク分析
メールキャンペーンや広告プラットフォームからのトラッキングURLをデコードし、埋め込まれたUTMパラメータやリダイレクトチェーンを理解します。
URL構造の検査
複雑なURLをコンポーネント部分——プロトコル、ホスト、ポート、パス、クエリパラメータ、フラグメント——に解析し、分析と変更を行います。

技術的な詳細

RFC 3986 予約文字と非予約文字
RFC 3986は、エンコード不要な非予約文字(A-Z、a-z、0-9、-、.、_、~)と、URI区切り文字として機能し、データとして使用する場合はパーセントエンコードが必要な予約文字(:、/、?、#、[、]、@、!、$、&、'、(、)、*、+、,、;、=)を定義しています。
UTF-8バイトエンコードフロー
非ASCII文字はまずUnicodeコードポイントに変換され、次にUTF-8バイト(コードポイント範囲に応じて1-4バイト)にエンコードされ、最後に各バイトが%XXとしてパーセントエンコードされます。例:é(U+00E9)→ UTF-8バイト C3 A9 → %C3%A9。絵文字🎉(U+1F389)→ UTF-8バイト F0 9F 8E 89 → %F0%9F%8E%89。
URLとURIの用語
URI(Uniform Resource Identifier)は任意の識別子文字列の一般的な用語です。URL(Uniform Resource Locator)はアクセスメカニズム(https://など)も指定するURIです。RFC 3986のエンコードルールはすべてのURIに適用されます。JavaScriptのAPIはURI用語(encodeURI、decodeURI)を使用し、日常的にはURLが好まれます。

ベストプラクティス

用途に応じて正しいモードを選択
個々のクエリパラメータのキーと値にはencodeURIComponent()を使用してください。完全なURLがあり、構造を壊さずに安全でない文字をエンコードしたい場合にのみencodeURI()を使用してください。&、=やその他の予約文字を含む可能性のあるパラメータ値にencodeURI()を使用しないでください。
二重エンコードを避ける
文字列をエンコードする前に、既にエンコードされているか確認してください。既存の%シーケンスを探します。既にエンコードされた文字列をエンコードすると、%20が%2520に、%3Dが%253Dになります。不明な場合は、まずデコードしてから一度エンコードしてください。
サーバーサイドでデコード
ほとんどのWebフレームワークは、アプリケーションコードが参照する前にURLパラメータを自動的にデコードします。フレームワークが既にデコードしたパラメータを手動でデコードすることは避けてください——元の値にリテラルのパーセントシーケンスが含まれていた場合、問題が発生する可能性があります。
OAuthとAPI署名のための値のエンコード
OAuth 1.0署名ベース文字列と多くのAPI署名アルゴリズムは、厳密なRFC 3986パーセントエンコードを必要とします。encodeURIComponent()を使用し、仕様が要求する場合はエンコードされない残りの文字(!、'、(、)、*など)をパーセントエンコードの等価物に置き換えてください。

よくある質問

URLエンコードとは何ですか?なぜ必要なのですか?
URLエンコード(パーセントエンコードとも呼ばれます)は、RFC 3986で定義された、URIで許可されていない文字を表現するためのメカニズムです。URLにはUS-ASCII文字セットの限られた文字のみ含めることができます——英字(A-Z、a-z)、数字(0-9)、およびハイフン、アンダースコア、ピリオド、チルダなどの少数の特殊文字です。この安全なセット外の文字は、パーセント記号(%)に続く2桁の16進数でエンコードする必要があります。例えば、スペースは%20に、スラッシュは%2Fに、アンパサンドは%26になります。このエンコードが必要なのは、&、=、?、#などの文字がURLで特別な構造的意味を持つためです。エンコードしないと、パラメータ値内の&がパラメータ区切り文字として誤解され、URL構造が完全に壊れます。URLエンコードにより、含まれる文字に関係なく、データがHTTPインフラストラクチャを通じて正常に送受信されることが保証されます。
encodeURIとencodeURIComponentの違いは何ですか?
これら2つのJavaScript関数は異なる目的を持ち、異なる文字セットをエンコードします。どちらを使うべきか理解することが、URLの不具合を避ける上で重要です。encodeURI()は完全なURIのエンコード用に設計されています。URLで構造的意味を持つ文字——コロン(:)、スラッシュ(/)、疑問符(?)、ハッシュ(#)、アンパサンド(&)、等号(=)——を保持します。完全なURL文字列があり、その構造を変えずに安全でない文字(スペースや非ASCII文字など)だけをエンコードしたい場合にencodeURI()を使います。例えば、encodeURI('https://example.com/path name')は'https://example.com/path%20name'を生成し、://と/は保持されます。encodeURIComponent()ははるかに積極的で、:、/、?、#、&、=を含むほぼすべての非英数字文字をエンコードします。これにより、URL内に配置される個別の値——最も一般的にはクエリパラメータ値——のエンコードに適しています。&を含むパラメータ値にencodeURI()を使うと、&はエンコードされずにパラメータ区切り文字として誤解されます。encodeURIComponent()は正しく%26にエンコードします。経験則:パラメータのキーと値にはencodeURIComponent()を、構造的区切り文字を保持する必要がある完全なURLのエンコードにのみencodeURI()を使用してください。
URLエンコードとHTMLエンコードは同じですか?
いいえ、まったく異なるエンコード方式で、異なる目的のために設計されています。URLエンコード(パーセントエンコード)は、RFC 3986で定義されているように、文字をURL内で安全に使用するための%XX 16進シーケンスに変換します。HTMLエンコード(HTMLエンティティエンコードとも呼ばれます)は、HTML仕様で定義されているように、文字を&(&用)、<(<用)、"(ダブルクォート用)などのエンティティ参照に変換します。URLエンコードはURL内のデータ転送用で、HTMLエンコードはHTMLドキュメント内でコンテンツを安全に表示するためのものです。よくある間違いは、HTMLエンコードをURLパラメータに適用したり、その逆を行うことです。
curlコマンドでURLが壊れるのはなぜですか?
特殊文字を含むURLをcurlなどのシェルコマンドに貼り付けると、シェルがcurlより先に&、?、(、)、#などの文字を解釈します。アンパサンド(&)はシェルに前のコマンドをバックグラウンドで実行するよう指示します。疑問符(?)はファイル名のグロビングを起動します。ハッシュ(#)はコメントを開始し、それ以降のすべてが無視されます。これを修正するには、シェルでURLを常にシングルクォートで囲みます:curl 'https://example.com/api?key=value&page=2#section'。シングルクォートはシェルが特殊文字を解釈するのを防ぎます。バックスラッシュで個々の文字をエスケープすることもできますが、URL全体をクォートする方が簡単でエラーが少なくなります。
URLで中国語文字が%E4%B8%ADのような文字列になるのはなぜですか?
中国語文字(およびすべての非ASCII文字)は、まずUTF-8バイト表現に変換され、各バイトがパーセントエンコードされます。例えば、「中」の文字はUnicodeコードポイントU+4E2Dです。UTF-8では3バイト:0xE4、0xB8、0xADで表現されます。各バイトはパーセント記号に続く2桁の16進数として書かれ、%E4%B8%ADとなります。この3段階のプロセス——文字からUnicodeコードポイント、コードポイントからUTF-8バイト、バイトからパーセントエンコード16進数——が、1つの中国語文字がURL内で9文字(%XX%XX%XX)に拡張される理由です。同じ原理は絵文字にも適用され、通常4つのUTF-8バイトが必要なため、パーセントエンコード時には12文字になります。
OAuthのredirect_uriパラメータはエンコードすべきですか?
はい、絶対に必要です。OAuthフローのredirect_uriは、別のURLのクエリパラメータ値として埋め込まれる完全なURLです。エンコードしないと、リダイレクトURI内の特殊文字——特に?、&、=——が、パラメータ値内のリテラル文字ではなく、外側のURL構造の一部として誤解されます。例えば、エンコードなしのredirect_uri=https://myapp.com/callback?code=abc&state=xyzは、認可サーバーがredirect_uriをhttps://myapp.com/callback?code=abcのみと見なし、state=xyzは外側のURLの別パラメータとして解析されます。正しくエンコードされた版はredirect_uri=https%3A%2F%2Fmyapp.com%2Fcallback%3Fcode%3Dabc%26state%3Dxyzです。リダイレクトURIの値全体に対して常にencodeURIComponent()を使用してください。
Node.jsのquerystringとURLSearchParamsの違いは何ですか?
Node.jsはクエリ文字列を処理する2つのAPIを提供しています:レガシーのquerystringモジュールと新しいURLSearchParamsクラス(WHATWG URL標準の一部)。querystringモジュールは独自のエンコードロジックを使用し、デフォルトでスペースを%20としてエンコードし、配列処理にいくつかの特徴があります(key=1&key=2が{ key: ['1', '2'] }になります)。URLSearchParamsはブラウザ標準に従います:application/x-www-form-urlencoded形式でスペースを+としてエンコードし、getAll()で重複キーを自動処理し、entries()、keys()、values()メソッドによるイテラブルインターフェースを提供します。新規プロジェクトでは、ブラウザの動作と一致し、標準準拠で、Node.jsとブラウザで同一に動作するURLSearchParamsが推奨されます。
Python、JavaScript、JavaでURLをエンコードする方法は?
JavaScriptでは、パラメータ値にencodeURIComponent()を、完全なURLにencodeURI()を使用します。例:const encoded = encodeURIComponent('hello world'); は'hello%20world'を生成します。Python 3では、パスセグメントにurllib.parse.quote()を、クエリパラメータにurllib.parse.urlencode()を使用します。例:from urllib.parse import quote; quote('hello world')は'hello%20world'を生成します。完全なクエリ文字列:from urllib.parse import urlencode; urlencode({'q': 'hello world'})は'q=hello+world'を生成します。Javaでは、パラメータ値にURLEncoder.encode(value, StandardCharsets.UTF_8)を使用します。JavaのURLEncoderはスペースを+としてエンコードする(フォームエンコーディング)ため、RFC 3986エンコーディングが必要な場合は+を%20に置換してください。
URLエンコードでエンコードされない文字はどれですか?
RFC 3986は、エンコード不要な「非予約文字」のセットを定義しています:大文字A-Z、小文字a-z、数字0-9、ハイフン(-)、ピリオド(.)、アンダースコア(_)、チルダ(~)。これら66文字はURLのどの部分にもそのまま使用できます。さらに、「予約文字」——:、/、?、#、[、]、@、!、$、&、'、(、)、*、+、;、=——は指定された構造的役割では許可されますが、リテラルデータとして使用する場合はパーセントエンコードが必要です。JavaScriptのencodeURIComponent()はA-Z a-z 0-9 - _ . ~と! ' ( ) *以外のすべてをエンコードし、encodeURI()はさらにURL区切り文字として機能する予約文字も保持します。
スペースのエンコードで+と%20の違いは何ですか?
+と%20はどちらもスペース文字を表しますが、異なる仕様に由来しています。+の規約はHTML仕様で定義されたapplication/x-www-form-urlencoded形式に由来し、ブラウザがHTMLフォームを送信する際に使用されます。この形式ではスペースが+としてエンコードされ、+文字自体は%2Bになります。%20エンコードはRFC 3986(URI構文)に由来し、すべての非予約文字がパーセント記号に続く2桁の16進数としてエンコードされます。現代の実践では、%20が普遍的に安全な選択です——URLのすべての部分(パス、クエリ、フラグメント)で機能します。スペースの+エンコードはフォームエンコーディング使用時のクエリ文字列でのみ有効です。URLパスセグメントで+を使用すると、スペースではなくリテラルのプラス記号として解釈されます。迷ったら%20を使ってください。
URLエンコードは絵文字をどのように処理しますか?
絵文字は他のUnicode文字と同じUTF-8パーセントエンコードプロセスでエンコードされますが、より多くのバイトが必要です。ほとんどの絵文字はU+1F000からU+1FFFF(またはそれ以上)の範囲のコードポイントを使用し、UTF-8エンコードでは4バイトが必要です。各バイトがパーセントエンコードされるため、1つの絵文字文字は通常URL内で12文字に拡張されます。例えば、ロケット絵文字(🚀、U+1F680)はUTF-8でバイトF0 9F 9A 80としてエンコードされ、URL内では%F0%9F%9A%80になります。肌の色修飾子やZWJシーケンスを持つ一部の絵文字は複数のコードポイントで構成され、エンコード時に30文字以上に拡張されることがあります。
URLエンコードは暗号化やセキュリティに使えますか?
いいえ。URLエンコードは暗号化ではなく、セキュリティは一切提供しません。純粋に機械的で、決定論的で、完全に可逆な変換です——誰でも鍵やシークレットなしにパーセントエンコードされた文字列を即座にデコードできます。URLエンコードは、構造的意味を持つ文字をエスケープすることで、任意のデータをURL内で安全に転送するためだけに存在します。URLエンコードを難読化やセキュリティの一形態として扱うのは危険な誤解です。URL内のパスワード、トークン、個人情報などの機密データは、URLエンコードではなくHTTPS(リクエスト全体のTLS暗号化)で保護すべきです。
URLの最大長はどれくらいですか?
HTTP仕様(RFC 7230)はURLの最大長を定義していませんが、各レイヤーで実用的な制限が存在します。ほとんどの最新ブラウザは約2,048文字のURL(Internet Explorerの歴史的制限)をサポートしていますが、ChromeやFirefoxは100,000文字を超えるURLも処理できます。Webサーバーは独自の制限を設けています:Apacheのデフォルトは8,190バイト、Nginxは8,192バイト、IISはクエリ文字列で16,384バイトです。CDNやプロキシはさらに厳しい制限を持つ場合があります。URLエンコードが文字を拡張する場合——特に非ASCIIテキスト——一見短いURLでもすぐにこれらの制限に近づく可能性があります。最大の互換性のため、URLは2,000文字以下に保つことがベストプラクティスです。
URLとURIの違いは何ですか?
URI(Uniform Resource Identifier、統一資源識別子)はより広い概念で、リソースを識別する任意の文字列です。URL(Uniform Resource Locator、統一資源位置指定子)は、アクセスメカニズム(プロトコル)とネットワーク上の場所を記述することでリソースの場所も提供する特定のタイプのURIです。例えば、https://example.com/pageはURIでありURLでもあります。リソースを識別し、アクセス方法(example.comでHTTPS経由)も示しているからです。urn:isbn:0451450523のようなURN(Uniform Resource Name)はURIですがURLではありません——ISBNで本を識別しますが、どこで見つけられるかは示していません。日常のWeb開発では、URLとURIという用語はしばしば互換的に使用され、RFC 3986で定義されたエンコードルールは両方に適用されます。

Base64エンコーダー&デコーダー

エンコーディングとフォーマット

Base64のデコード・エンコードが無料でオンラインで行えます。リアルタイム変換、UTF-8・絵文字対応。100%ブラウザ上で動作しデータは外部に送信されません。登録不要。

JSONフォーマッター&バリデーター

エンコーディングとフォーマット

無料オンラインJSON整形ツール。ブラウザ上でJSONのフォーマット、構文検証、圧縮を即座に実行。エラー検出、ワンクリックコピー対応。データは端末外に送信されず、100%プライバシー保護。

進数変換ツール — 2進数・16進数・10進数・8進数

単位変換

無料オンライン進数変換ツール。2進数、8進数、10進数、16進数および任意の基数(2-36)間で数値を瞬時に変換。BigInt対応で桁数制限なし。登録不要・サーバー送信なし、すべての処理がブラウザ内で完結。コピーボタンやコードリテラル出力で開発作業を効率化。

JPEG・PNG・WebP をオンラインで圧縮 — 無料・一括対応

単位変換

無料オンライン画像圧縮ツール。JPEG、PNG、WebP 画像をブラウザ上で最大 80% 縮小。サーバーへのアップロード不要で完全プライベート。最大 20 枚の一括圧縮、品質調整、圧縮前後の比較機能を搭載。登録不要ですぐに使えます。

長さ単位変換ツール — メートル法・ヤードポンド法・天文単位対応

単位変換

1インチ = 2.54 cm、1フィート = 0.3048 m、1マイル = 1.609 km。メートル法・ヤードポンド法・海里・天文単位を含む16種類の長さ単位を即時変換。無料、ブラウザ完結、データ送信なし。

MD5ハッシュジェネレーター&ファイルチェックサムツール

セキュリティツール

無料オンラインMD5ハッシュ生成ツール。ブラウザ上でMD5・SHA-256・SHA-1・SHA-512のハッシュ値を即座に生成。テキストやファイルのチェックサム検証・比較、ワンクリックコピー対応。登録不要でデータはサーバーに送信されません。