HTMLフォームのGET・POSTの違いとは？送信データの見え方と使い分けを初心者向けに解説

2026年8月25日2026年10月14日

フォームを書いたとき、「GETとPOSTはどちらを選べばよいのか」「POSTなら安全なのか」と迷っていませんか。入力欄の見た目が同じでも、送信方法によってデータの置き場所と、サーバーへ依頼する処理の意味が変わります。

まずは、検索など情報を取得するフォームにはGET、問い合わせや登録などの処理を依頼するフォームにはPOST、と目的から考えましょう。ただし、POSTを指定するだけで通信が暗号化されるわけではありません。

この記事は、form・input・buttonの基本を学んだ方に向けた解説です。同じ入力値の見え方、用途別の選び方、ブラウザーのNetworkで見る項目を整理し、自分のフォームで確認すべき点を判断できるようにします。受信側プログラムの作成は扱わず、コードを試すための条件も併せて説明します。

この記事で分かること

GETとPOSTで送信データが置かれる場所の違い
検索・絞り込みと、登録・更新・問い合わせでの使い分け
POSTとHTTPS、サーバー側の入力検証の役割の違い
GET／POSTのフォームをコードで書き、送信結果を予測する方法
ブラウザーのNetworkで送信内容と応答を見るポイント

GET・POSTの違いの早見表

GETとPOSTは、どちらもブラウザーからサーバーへHTTPリクエストを送る方法（HTTPメソッド）です。HTMLフォームでは、form要素のmethod属性で指定します。

まずは、初心者が使い分けるときに重要な違いを整理しましょう。

ここで使う4つの言葉を先に確認します。

HTTPリクエスト：ブラウザーからサーバーへ送る「この処理をしてください」という依頼
クエリー文字列：URLの?以降に付くname=value形式のデータ
リクエスト本文（body）：URLとは別に、HTTPリクエスト内へ入れて送るデータの領域
サーバーの状態：問い合わせ、注文、会員情報など、サーバー側に保存されている内容

比較する点	GET	POST
フォームデータの場所	URLのクエリー文字列	HTTPリクエストの本文
主な目的	検索・絞り込み・一覧表示など、情報の取得	登録・更新・問い合わせなど、サーバー側での処理
URLからの再表示	条件を含むURLを共有・保存しやすい	リクエスト本文はURLへ含まれない
同じ操作の繰り返し	サーバーの状態を変えない処理に使う	同じ送信で処理が重複する可能性がある
長い文章・ファイル	向かない	長い文章に向く。ファイルは追加設定が必要
安全性	機微情報をURLへ入れない	暗号化ではない。HTTPSなどが別途必要

通常のHTMLフォームでサーバーへ送信するときは、method属性にgetまたはpostを指定します。本記事では、この2つを扱います。

method属性を省略した場合、HTMLの既定値はGETです。問い合わせフォームのつもりで省略すると、入力値がURLへ加わるため注意してください。

GETのURLにkeyword=東京、POSTのリクエスト本文にkeyword=東京が入る模式図 — 通常のHTMLフォームから送るリクエストを模式化しています。背景色の付いた領域が入力値の置き場所です。「東京」は読みやすい表記で、実際にはエンコードされます。

図のとおり、GETとPOSTで入力欄そのものが変わるわけではありません。ブラウザーがname=valueを組み立てた後、GETならURL、POSTならリクエスト本文へ入れて送ります。

HTMLフォームにおけるmethodの仕様は、MDNのform要素リファレンスでも確認できます。

HOAI Point

GET／POSTは「URLに見える方・見えない方」だけで選びません。 処理が情報の取得なのか、登録・更新などの状態変更なのかを先に判断し、そのうえでURLの再利用性やデータ量を確認すると迷いにくくなります。

action属性とmethod属性の役割を先に確認したい場合は、HTMLフォームのaction・method属性の書き方も参考にしてください。

GETのデータ形式と用途

GETは、検索結果や一覧などの情報を取得するためのHTTPメソッドです。通常のHTMLフォームからHTTP／HTTPSで送ると、フォームデータがaction属性のURLのクエリー文字列になります。

GETフォームの基本コード

検索フォームの例を見てみましょう。

<form action="/search" method="get">
  <label for="keyword">検索キーワード</label>
  <input id="keyword" name="keyword" type="search" />

  <button type="submit">検索する</button>
</form>

入力欄へ「東京」と入力して送信すると、ブラウザーはおおむね次のURLを作ります。

https://example.com/search?keyword=%E6%9D%B1%E4%BA%AC

?より後ろがクエリー文字列です。keywordは入力欄のname、%E6%9D%B1%E4%BA%ACは「東京」をURLで扱える形へ変換した値です。この変換をパーセントエンコードと呼びます。

URLでは別の文字に見えても、受信側では元の文字へ戻す処理（デコード）によって「東京」として扱えます。見えている文字列をそのまま入力値と取り違えないようにしましょう。

なお、GETフォームでは、action="/search?from=guide"のように送信先へ元から書いたクエリー文字列は、フォームデータから作られるものに置き換わります。from=guideも送りたい場合は、<input type="hidden" name="from" value="guide">をフォーム内に置きます。hiddenは画面に表示しない入力欄で、値を秘密にする機能ではありません。

この動作は、HTML標準のGET送信処理で確認できます。

GETが向いている用途

検索・絞り込み・並べ替え・ページ切り替えなど、何度実行してもサーバー上の登録内容を変えない処理にはGETが向いています。

たとえば、次のようなフォームです。

サイト内検索
商品一覧の価格帯やカテゴリーによる絞り込み
記事一覧の並べ替え
公開データの表示条件の指定

検索条件がURLに含まれるため、結果ページを再読み込みしたり、URLをコピーして同じ条件を共有したりしやすい利点があります。

補足として、HTTPでは、利用者がサーバーの状態変更を要求しないメソッドを「安全なメソッド（safe method）」と呼びます。ここでいう「安全」は、通信が暗号化されるという意味ではありません。アクセスログの記録などは起こり得ますが、GETで登録・更新・削除を要求しないことが大切です。

GETへ入れない方がよいデータ

GETのクエリー文字列は、アドレスバー、ブラウザー履歴、共有したリンク、受信側のサーバーログなどに残る可能性があります。HTTPSを使っていても、URLの保存・共有先で内容が見える点は変わりません。

そのため、次のようなデータをGETのURLへ入れないでください。

パスワード
認証トークンや秘密のコード
問い合わせ本文など公開を想定しない長文
URLに残す必要のない個人情報

また、URLには環境ごとの実用上の長さ制限があります。長い文章や大量の入力値を送る用途にはGETを選ばない方がよいでしょう。

POSTのデータ形式と用途

POSTは、送信したデータを使ってサーバー側に処理を依頼するHTTPメソッドです。HTMLフォームでは、フォームデータがHTTPリクエストの本文へ入ります。

POSTフォームの基本コード

問い合わせフォームの例です。

<form action="/contact/submit" method="post">
  <label for="email">メールアドレス</label>
  <input id="email" name="email" type="email" />

  <label for="message">お問い合わせ内容</label>
  <textarea id="message" name="message"></textarea>

  <button type="submit">送信する</button>
</form>

このフォームの入力値はURLへ追加されず、リクエスト本文へ入ります。送信先のURLは次のとおりです。

https://example.com/contact/submit

メール欄にuser@example.com、本文欄に「質問です」と入力したとします。既定のapplication/x-www-form-urlencoded形式では、リクエスト本文へおおむね次のデータが入ります。

email=user%40example.com&message=%E8%B3%AA%E5%95%8F%E3%81%A7%E3%81%99

%40は@、後半のパーセントエンコードされた文字列は「質問です」に対応します。POSTでも、入力部品のnameと現在の値からname=valueが組み立てられる点はGETと同じです。

ただし、POSTでもaction="/contact/submit?from=guide"のように送信先URLに元から指定したクエリー文字列は残ります。「POSTのURLには?が付かない」という意味ではありません。フォームの入力値がどこへ入るかを区別してください。

POSTが向いている用途

POSTは、次のようにサーバー側の状態を変えたり、入力内容を処理したりするフォームで一般的に使われます。

問い合わせの送信
アカウントの登録
注文の確定
コメントの投稿
登録済みデータの更新
長い文章の送信

同じPOSTを複数回送ると、問い合わせや注文が重複して登録される可能性があります。受信側では二重送信対策を行い、利用者側でも送信後の再読み込みや戻る操作に注意します。

POSTとHTTPSの役割の違い

POSTはフォームデータをリクエスト本文へ入れる送信方法であり、通信を暗号化する機能ではありません。

HTTPのまま送信すれば、POSTのリクエスト本文も通信経路で保護されません。HTTPSを使うと、GETのクエリー文字列もPOSTのリクエスト本文も通信経路上では暗号化されます。ただし、GETのURLはアドレスバー、ブラウザー履歴、共有したリンク、サーバーログなどに残る可能性があります。

個人情報や認証情報を扱うフォームではHTTPSを使い、サーバー側でも入力値の検証、権限確認、CSRF対策（別のサイトから利用者の意図しない送信を行わせる攻撃への対策）、ログや保存データの管理を行います。

HOAI Point

POSTは送信方法、HTTPSは通信経路の保護、サーバー側の検証は受け取った値の安全確認です。 3つは代わりになりません。「POSTにしたから安全」と判断せず、役割を分けて設計してください。

ファイルを送る場合は、POSTに加えてenctype="multipart/form-data"を指定します。ファイル送信は設定項目が増えるため、まず通常のテキスト送信でGET／POSTの違いを理解してから扱うと整理しやすいでしょう。

GET・POSTを選ぶ判断基準

GETとPOSTで迷ったら、最初に「サーバー上の情報を読むだけか」「登録・更新などの変化を起こすか」を確認します。

検索・絞り込みで使うGET

検索結果や絞り込み結果など、同じ条件で何度開いても登録内容が変わらない処理はGETが基本です。結果条件を含むURLを共有・保存したい場合にも合います。

登録・更新で使うPOST

問い合わせ送信、登録、更新、注文など、サーバー側で処理結果を保存したり状態を変えたりする場合はPOSTが基本です。長文やファイルなど、URLへ含めるべきでないデータにもPOSTを使います。

受信側の仕様との一致

フォーム側のmethodは、送信先が受け付けるHTTPメソッドと一致させる必要があります。送信先がPOSTだけを受け付けるなら、フォーム側もPOSTに合わせます。逆に、検索の送信先がGETを前提としているならGETを使います。

受信側と異なるメソッドを送ると、405 Method Not Allowedなどのエラーになることがあります。HTMLを書く前に、送信先URL、受け付けるHTTPメソッド、必要な項目名を確認してください。

同じ入力欄でGET・POSTを比べるコード

次の例では、同じ項目名keywordの入力値をGETとPOSTで送ります。/searchと/contact/submitは説明用の送信先です。前者でGET、後者でPOSTを受け付ける、自分が管理する学習用の環境を前提にしています。

このコードだけでは検索・保存・メール送信は完成しません。 実行する場合は、HTMLをUTF-8で保存し、学習用サーバーを通じてHTTP／HTTPSのURLで開きます。file:でHTMLファイルを直接開いた場合は同じ比較になりません。受信処理がまだなければ実行せず、下の予想問題をコードの読み比べだけで解いてください。GETはURL、POSTはリクエスト本文へ値が入ると説明できれば、この段階の学習は完了です。Networkでの実測は、受信側を用意した後に進めます。

<!doctype html>
<html lang="ja">
  <head>
    <meta charset="UTF-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
    <title>GETとPOSTの比較</title>
  </head>
  <body>
    <h1>GETとPOSTの比較</h1>

    <h2>GETで検索する</h2>
    <form action="/search" method="get">
      <label for="get-keyword">検索キーワード</label>
      <input id="get-keyword" name="keyword" type="search" />
      <button type="submit">GETで送信</button>
    </form>

    <h2>POSTで送信する</h2>
    <form action="/contact/submit" method="post">
      <label for="post-keyword">送信する文字</label>
      <input id="post-keyword" name="keyword" type="text" />
      <button type="submit">POSTで送信</button>
    </form>
  </body>
</html>

どちらの入力欄もname="keyword"なので、送信データの項目名はkeywordです。違うのは、GETでは値がURLへ加わり、POSTではリクエスト本文へ入る点です。

HTMLで入力欄・送信先・方法を指定し、ブラウザーが送信、サーバーが処理する流れ — HTMLの指定をもとにブラウザーが送信し、検索・保存などの処理はサーバー側で行います。

図のように、HTMLは入力欄や送信先の指定、ブラウザーは送信データの組み立てと送信、サーバーは受信したデータの処理を担当します。actionのURL・method・項目名が受信側の仕様に合っていることを確認してください。HTMLの配信だけを行う簡易サーバーでは、POSTを受け付けない場合があります。

フォームを構成する要素の役割は、HTMLのform・input・label・buttonの違いで確認できます。nameとvalueの基本は、HTMLのinputタグの書き方も参考にしてください。

入力値と送信データの対応

コードを試す前に、入力値を「東京」としたときの結果を予想してみましょう。

GETフォームの送信方法は何になるか
GETの送信先URLへどの項目と値が入るか
POSTの入力値はURLとリクエスト本文のどちらに入るか

答えは、1がGET、2がkeyword=東京（実際のURLではパーセントエンコードされた表記になります）、3がリクエスト本文です。受信環境がない方は、この対応が分かれば次のNetwork節を読み飛ばして構いません。受信側を用意して試す方は、「東京」などの架空の入力で次の項目を確認してください。

Networkで見る送信内容と応答

Network（ネットワーク）は、ブラウザーとサーバーの通信を確認する開発者ツールの機能です。この節は、GET／POSTの両方を受け付ける学習環境がある方向けの確認項目リファレンスです。Chrome DevToolsを例に、何を見比べるかを整理します。表示言語や版によって表記は異なります。

確認対象は、学習用フォームから最初に送ったリクエストです。Networkでその通信を選び、以下の3か所を照合します。ページ移動がある場合は、送信前にPreserve log（ログを保持）を有効にすると記録を残せます。開き方や画面の操作は、この節末のChrome公式リファレンスを参照してください。

Headersで見る送信方法とURL

Headers（ヘッダー）のRequest MethodはGETかPOSTかを示し、Request URLは実際の送信先を示します。まず、コードで指定した送信方法とURLに対応しているかを照合します。

GETでは送信先URLにフォームデータが付きます。POSTの後に別のページへ転送（リダイレクト）されると、一覧に後続のGETが現れる場合があります。最後に表示されたページのアドレスだけで判断せず、フォームから最初に送ったリクエストを見てください。

Payloadで見る項目名と入力値

Payload（ペイロード）は、送信したデータを確認する場所です。今回の通常のHTMLフォームでは、GETはQuery String Parameters、POSTはForm Dataにあるkeywordと「東京」が確認対象になります。

読める形へ戻された表示と、エンコードされたソース表示を切り替えられるため、「東京」と%E6%9D%B1%E4%BA%ACの両方が現れ得ます。POSTでも送信先に元からクエリー文字列があれば、クエリーとフォームデータの両方が表示されます。

Status・Responseで見る処理結果

Status／Status CodeはHTTPの応答状態、Response（レスポンス）はサーバーから返された内容です。404なら送信先URLや受付処理、405なら許可されている送信方法を調べる手がかりになります。

送信データが見えることと、保存などの処理が完了したことは別です。 200でも入力エラーの画面が返る場合があります。完了画面やレスポンスに加え、必要なら自分が管理する受信側の記録で、予定した検索・保存・通知が行われたことを確かめます。

各パネルの画面例や詳しい操作は、Chrome DevToolsのNetworkリファレンス（日本語）で確認できます。フォームの送信形式と受信側の関係は、MDNのフォームデータの送信も参考になります。

GET・POSTでよくある間違いと確認方法

当てはまる症状の項目だけ確認してください。受信処理が未準備の場合は、送信を繰り返しても解決しません。URL・送信方法・項目名が受信側の仕様と一致し、意図した結果を確認できたら、その確認は終了です。

methodを省略して意図せずGETになる

methodを省略すると既定値はGETです。問い合わせや登録を作る場合は、受信側の仕様を確認してmethod="post"を明示します。

<!-- methodを省略しているためGET -->
<form action="/contact/submit">
  <!-- 入力部品 -->
</form>

GETで登録・削除などの処理を実行する

GETは情報の取得に使うメソッドです。リンクの先読み、検索エンジンの巡回、再読み込みなどで同じURLが意図せず呼ばれることもあります。登録・更新・削除などの状態変更をGETへ割り当てないでください。

POSTなら安全だと思い込む

POSTでもHTTPSを使わなければ通信経路は暗号化されません。HTTPS、サーバー側の入力検証、権限確認、CSRF対策を別々に確認します。

受信側とmethodが一致していない

フォームがPOSTを送っていても、送信先がGETしか受け付けなければ処理できません。NetworkでRequest Methodとステータスコードを確認し、サーバー側のルート設定と照合します。

POSTの値をアドレスバーで探す

POSTのフォームデータは通常、リクエスト本文に入ります。アドレスバーではなく、NetworkのPayloadにあるForm Dataを確認してください。

nameがなく値が送られない

nameがない入力部品の値は、通常のフォーム送信では送られません。 idはlabelとの関連付けなどに使いますが、送信項目名の代わりにはなりません。

<!-- 画面では入力できるが、通常のフォームデータに項目名がない -->
<input id="email" type="email" />

<!-- nameを付ける -->
<input id="email" name="email" type="email" />

よくある質問

method属性を書かないとGETとPOSTのどちらになりますか？: GETになります。HTML標準ではmethodの未指定時と不正な値の既定がGETです。登録・問い合わせなどPOSTを使う処理では、method="post"を明示してください。
パスワードはPOSTなら安全に送れますか？: POSTだけでは安全になりません。パスワードをURLへ出さないためGETは避け、POSTとHTTPSを使います。さらに、サーバー側で認証、入力検証、保存方法、ログへの出力を適切に設計する必要があります。
GETのURLはブックマークできますか？: はい。検索条件などを含むURLをブックマークすれば、同じ条件の結果を開きやすくなります。ただし、サーバー側のデータ更新やログイン状態によって結果が変わる場合があります。機微情報を含むURLは保存・共有しないでください。
POSTの送信内容は完全に見えなくなりますか？: いいえ。入力値がURLへ自動追加されないだけで、ブラウザーの開発者ツールや受信側のプログラムでは確認できます。ログに残るかどうかは受信側の実装次第です。見えにくさと暗号化を混同しないでください。
ファイルを送る場合はGETとPOSTのどちらですか？: POSTを使い、form要素へenctype="multipart/form-data"、ファイル選択欄へtype="file"とnameを指定します。受信側でもファイルを受け取る処理、容量・形式の検証、安全な保存先が必要です。
JavaScriptのfetchでもGETとPOSTの考え方は同じですか？: 基本的なHTTPメソッドの意味は同じです。ただし、fetch()ではヘッダーやリクエスト本文をJavaScriptで組み立てます。まずHTMLフォームでGET／POSTの役割を理解し、その後に非同期送信へ進むと整理しやすいでしょう。