プロトコルは2011年5月の完成を目標に進められていたが、その期日を過ぎても仕様の改訂は続けられ、2011年7月11日に最終草案のdraft-ietf-hybi-thewebsocketprotocol-10が勧告されたが、さらにその後も改訂は続き、2011年9月30日に draft-ietf-hybi-thewebsocketprotocol-17がリリースされ、それが2011年12月11日にRFC 6455のproposed standard（標準化への提唱）となった。2010年11月26日にdraft-ietf-hybi-thewebsocketprotocol-03やそれ以前のWebSocketのプロトコルにセキュリティホールが発見され、2010年12月に、一時的に、Firefox 4とOpera 11のWebSocketが無効になり、Chromeはプロトコル改訂よりも先に攻撃コードが出た場合は無効にするとしていた。Opera 11はopera:config#Enable%20WebSocketsを開き、設定を有効にすると利用可能。その後、2011年1月11日にdraft-ietf-hybi-thewebsocketprotocol-04が発表され、サーバにアップロード通信する際はプロキシを混乱させないために、通信内容をXORでマスキングさせる方法となった。2011年8月16日に再度WebSocketに対応させた、Firefox 6 がリリースされたが、まだ、仕様の改訂が続くという理由から、Firefox 10までは、MozWebSocketと頭にMozがつく形となった。Firefox for Mobileは7から対応。ウェブブラウザで動作するJavaScript用のAPIの策定は、当初W3Cで行われていた。その後、HTML5とともにWHATWGに移ることとなった。
WebSocketの接続を確立するために、クライアント側はまずハンドシェイク要求を送る。そして、サーバ側はハンドシェイク応答を返す。以下がその例である。ウェブブラウザが以下の要求をサーバ側に送る：GET /chat HTTP/1.1Host: server.example.comUpgrade: websocketConnection: UpgradeSec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==Origin: http://example.comSec-WebSocket-Protocol: chat, superchatSec-WebSocket-Version: 13サーバ側は以下の応答を返す。HTTP/1.1 101 Switching ProtocolsUpgrade: websocketConnection: UpgradeSec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=Sec-WebSocket-Protocol: chatハンドシェイクはHTTPの様であるが、厳密には異なる。サーバ側は最初HTTPの要求として解釈し、そして、WebSocketへと切り替える。
XMLHttpRequestの欠点を解決する技術として開発されており、現在のComet等に取って代わることを目標としている。いわゆるAjaxアプリケーションではサーバとクライアント間のデータのやり取りが頻繁に発生するが、従来のXMLHttpRequestはあくまでブラウザ側からサーバにデータの送信要求を出す手段に過ぎず、サーバ側からクライアントにデータをプッシュ配信することが難しい。一方Cometではサーバ側からのプッシュ配信が可能なものの、多くの実装では擬似的に双方向通信を行うため通信が発生するごとにTCPのハンドシェイク手続きを再度行う必要があるほか、HTTPコネクションを長時間占有するためその間同一サーバに接続する他のアプリケーションの動作に影響を及ぼす可能性があるなど、また別の問題が生じる（XMLHttpRequest#ロングポーリングも参照）。これに対しWebSocketでは、サーバとクライアントが一度コネクションを行った後は、必要な通信を全てそのコネクション上で専用のプロトコルを用いて行う。従来の手法に比べると、新たなコネクションを張ることがなくなる・HTTPコネクションとは異なる軽量プロトコルを使うなどの理由により通信ロスが減る、一つのコネクションで全てのデータ送受信が行えるため同一サーバに接続する他のアプリケーションへの影響が少ないなどのメリットがある。
従来規格のMPEG-1、MPEG-2やH.261では16×16画素、H.263、MPEG-4では8×8画素のブロック（マクロブロック）を単位として、原画像ないしフレーム間予測の予測誤差画像の離散コサイン変換 (DCT) 係数を求め、その係数を量子化している。このとき、コサイン関数を用いるため、実数精度の演算が必要となる。これに対しH.264では、16ビット整数精度で演算が可能な整数変換を採用している。この整数変換は、加減算とビットシフトのみによって演算可能となるように設計されているため、ソフトウェア、ハードウェアいずれの場合でも実装が非常に容易となる。演算がすべて整数精度で行われることで、実数演算の実装差による「デコーダごとの演算結果の差分」を生じさせることなくエンコードすることが可能となった。これは、エンコード時の局部復号器の結果とすべてのデコーダでの出力結果が全く同一になることを意味している。エンコード時の局部復号器の結果とデコーダの出力結果が異なる場合、エンコーダが作成する再構成画像とデコーダが作成する再構成画像が異なることとなるため、フレームが経過するごとに画像にノイズが蓄積してしまう。これを回避するため従来技術ではそのDCT演算誤差の帳消しのために定期的にイントラマクロブロックを挿入する必要があった。H.264では整数変換を用いており誤差の問題が生じないため、定期的にイントラマクロブロックを挿入する必要がない。デコーダの実装差による出力結果の違いが生じないことは、デコーダの規格適合性を検証する上でも有利となる。H.264の関連規格であるH.264.1はH.264規格適合性の検証手法を定めるもので、H.264で符号化済の試験用ビットストリームとそのデコード結果の組が多数付属している。開発中のデコーダに試験用ビットストリームを入力し、その出力結果とH.264.1付属のデコード結果が厳密に一致しているかどうかを確かめることで、規格適合性の判断を行うことができる。当初、H.264で使用可能な整数変換のブロックサイズは4×4画素のみだった。このサイズでは、低解像度の動画の圧縮では比較的好適な画質を示すが、HDTVなどのような高解像度の動画で画質の再現性に弱いという問題点があった。そのため、後に導入されたプロファイル群では、これを克服するために8×8サイズの整数変換が導入されている。これらのプロファイルでは、フレーム内で4×4変換と8×8変換を適応的に切り替えて使用することができる。