ブラウザーのオプション機能である、クッキー。
サーバー側で必要とする情報をクライアントのパソコン上に保持する。
クッキーは、サーバー側の指示により、情報をクライアントのマシン上に永続的に保持する機能。
クライアントがサーバーにアクセスする際には、マシン上に保持している“そのサーバー向けの情報（クッキー）”をサーバーに送信する。
永続的とは、一旦ブラウザーを閉じて（あるいはマシンの電源を切って）再度サーバーにアクセスしたときに前回の情報が残っているという意味。
クッキーは、ブラウザーのオプション機能。つまり必須ではないので、未対応のブラウザーも存在する。
また、セキュリティー上の観点からクッキーを嫌うユーザーも居り、クッキーを受け入れない設定にしているブラウザーも存在する。
つまり、Webアプリ構築の視点としては、「クッキーが常に使えるとは限らない」ということ。
対応していないブラウザーでは、クッキーが送られてきても無視するし、サーバーへクッキーを送ることもない。
したがって、サーバーからクライアントへクッキーを送ってみて、クライアントからの次の要求のときにクッキーが返ってこなければ未対応だと分かる。
サーバーからクライアントへのクッキーを送ることを「クッキーを食わせる」と言う人がいる。
単純に「クッキーを送る」と言った場合、「サーバーからクライアントへ」なのか「クライアントからサーバーへ」なのか区別できないのは確かだが。
クッキーには、名前を付けて値を保持する。
つまり複数の情報（名前）を保持することが出来るわけだが、クッキーの個数やサイズ（バイト数）の制限が多い。あまり多用できないと考えるべき。
有効期限はクッキー（の名前）毎に設定できる。ドメインやパス毎ではない。
| 情報 | 概要 |
|---|---|
| 名前 | クッキーの名前。 |
| 値 | 名前に紐付く情報。 |
| ドメイン | このクッキーを送受信するサーバーのドメイン名。 |
| パス | このクッキーを送受信するURLのパス名。 |
| 存続期間 | このクッキーの有効期間。この期間を過ぎたクッキーは破棄される。 |
| コメント | このクッキーのコメント。 |
| バージョン | このクッキーのバージョン。 |
| セキュア | このクッキーをSSL（HTTPS）のみで使うかどうか。 |
これらのクッキーの情報を指定するのは、サーバー側。
だが、JavaScriptでもクッキーを設定することが出来る。（JavaScriptが実行されるのはクライアント側）
しかし、JavaScriptをHTMLに埋め込んだのはサーバー側だから、「サーバー側の指示」であることに間違いは無いだろう。
IEの場合、クッキーは「C:\Documents and Settings\ユーザー\Cookies」のディレクトリ配下に、ドメイン/パス毎にファイルが作られて保存されている。
クライアントにクッキーを保持させる際に、ドメインとパスを指定する。
（明示的に指定しなかった場合は、その時点のサーバーのドメインとURLが使われる）
（自分自身のURLと無関係なパスを指定することも出来るが、その場合はそのクッキーは自分の所には送られてこない）
クライアントは、自分が保持している全クッキーのドメインとパスを調べて、該当するサーバーとURLにアクセスする時のみ、そのクッキーをサーバーへ送信する（該当するクッキーは全て）。
ドメインは後方一致で該当するかどうか判断される。
例えば「google.co.jp」で登録してあったとすると、「google.co.jp」そのものはもちろん、「www.google.co.jp」といった、前方が異なるものも対象に含まれる。
パスは、文字列として前方一致で該当するかどうか判断されるのだそうだ。
例えば「/sample」で登録してあったとすると、「/sample」そのものはもちろん、「/sample/sub」（サブディレクトリ扱い）が対象に含まれる。
かつ、文字列としてマッチするかどうか判断するので、「/sample_1」というURLでも（本来なら異なるディレクトリだが）対象に含まれる。
例えば/sample/c1.htmlで「/sample」というパスで「aaa=value1」というクッキーを保持し、
/sample/sub/c2.htmlで「/sample/sub」というパスで「bbb=value2」というクッキーを保持させたとすると、
「/sample/sub/c3.html」を開こうとしたブラウザーは、サーバーに「aaa=value1; bbb=value2」というクッキーを送信する。
「/sample/c4.html」を開こうとした場合は、「aaa=value1」というクッキーのみをサーバーに送信する。