プレーンテキスト（）とは、コンピュータ上で文章を扱うための一般的なファイルフォーマット、または文字列（テキスト）の形式である。テキスト形式データのうち、コンピュータに対する指示や付加情報などを含まず、見出しや文章など人間に意味のある文字のみで構成されるものを指す。一般的に、拡張子が「.txt」のテキストファイルは、プレーンテキスト形式であることが期待される。

 概要 
狭義ではASCIIのみ、さらに厳密には7ビットASCIIで構成された文書だけを指すが、ISO/IEC 8859-1やEUC-JP/Shift_JISのような各国の言語固有の文字コードあるいは国際標準規格のUnicodeなどで記述されたものも含める広義の用法が主流である。一般的に、テキストファイルは文字コード0で表されるヌル文字を含まず、これがバイナリファイルとの違いの1つとして挙げられる。

ワードプロセッサ（ワープロ）アプリケーションの代表格であるMicrosoft Wordのドキュメント形式（.doc/.docxなど）や、PDF形式などとは違い、文字の色・サイズ・フォントといった装飾情報、レイアウト（組版）情報、図表・画像・音声・動画などといった高度なマルチメディア情報を含まない。。しかし、マルチスタイルテキストの一部も、ファイルフォーマットとしてはプレーンテキストのみで構成されているものもある。

プレーンテキストには文字情報以外の情報はいっさい含まれず、テキストデータのみで構成されている。バイナリデータや文字の装飾情報を持たないので、最低限の機能しか持たないテキストエディタや表示用のソフトウェアでも扱えるという点で利便性が高い。その反面、格納できる情報が純粋にテキストのみに限定されるため、装飾情報やマルチメディア情報を持つことができない。これらの情報を格納する場合には、HTMLのような工夫が必要になる。また、テキストのエンコーディング情報を持たないので、ファイルを開く際に自動推定または仮定する必要があるが、判断に利用できるテキスト情報量が少ないと自動推定に失敗して文字化けする可能性がある（判別しやすいように先頭にバイトオーダーマークが付加されているものもある）。とはいえ、現代的なパーソナルコンピュータ（パソコン、PC）に搭載されているオペレーティングシステム（OS）では、UTF-8形式のプレーンテキストの表示や編集に標準対応しているので、文字コードを仮定することに問題がなければ可搬性や交換性が高いフォーマットである。Windowsではメモ帳、UNIXやLinuxの場合はviやEmacs、macOSの場合はテキストエディットなどといったOSに標準的に付属するソフトウェアで編集できる。なお、MS-DOSにはEDLIN（ラインエディタ）やMS-DOS Editorが、Classic Mac OSにはSimpleTextが付属していたが、これらはUnicodeが普及する前のレガシー環境であり、日本語の場合はMicrosoftコードページ932やMacJapaneseといったShift_JISから派生した独自拡張の文字コードが使われていた。

スマートフォンに標準搭載されているメモ系のアプリの保存データはプレーンテキストではなく、装飾情報などを含むことのできる独自の形式となっていることも多い。生のデータはベンダー各社で互換性がなく、異なる端末間でやりとりするには互換性のある形式でエクスポートする必要がある。ただし、コピー＆ペースト機能を使用して、プレーンテキスト情報としてアプリ間でデータのやりとりをすることはできる。

プレーンテキストはソフトウェアが解釈して処理すべき記述を含まず、人間にとって意味のある文字群と、空白や改行、タブ文字など最低限の表示制御を行う制御文字のみを含む。プログラミング言語のソースコードやHTML、XML、TeXといった形式は、純粋なテキストのみで構成されているテキストファイルの一種であり、一般的なテキストエディタで編集することもできるが、これらはプレーンテキストには分類されない。

HTML/XMLでは言語や文字エンコーディングを特定のタグや属性によって指定する。Pythonのソースコードは、デフォルトではUTF-8でエンコードされているものと仮定されるが、ソースファイル先頭の特別なコメント行（シバン）によってエンコーディングを指定することもできる。

 制御コード・制御情報 
先ほど、プレーンテキストはテキストデータのみで構成されると述べたが、正確には画面に表示される通常の文字（印字可能文字、空白も含む）のほか、文字としては表示されないが文字表示の制御などを行なう制御コードが含まれる。制御コードの例としては、文字の開始位置を揃える水平タブ (0x09)、垂直タブ (0x0B)、改行、改ページ (0x0C)、EOF（End Of File、ファイル終端マーク：0x1A）およびBOM（Byte Order Mark：Unicodeのように2バイト以上で1文字を構成する文字コードにおいてエンディアンを判別するための複数バイトからなる情報）などがある。このほか、各種文字コードの制御情報も含まれる。

これら制御コードに関し、OS間では互換性の問題が生じる。MS-DOS・Windows、UNIXおよびClassic Mac OSのプレーンテキストでは、それぞれ異なる改行コードを用いており、これが問題となることがありうる。

以下に、各OSの標準的な改行コードを挙げる。CRおよびLFはそれぞれASCIIの制御コードであり、CRは「復帰」を、LFは「改行」を表す。

 OS 改行コード MS-DOS・Windows CR+LF UNIX LF Classic Mac OS CR

MS-DOSは、CP/Mとの互換性を持たせるためにCR+LFを採用し、Windowsもそれを踏襲することになった。これはCRとLFの2つの制御コードを用いて1つの改行を表す形式であり、タイプライタでキャリッジ（印字するためのヘッド）を戻し（キャリッジリターン）、1行分を紙送り（ラインフィード）して、次の行を印字する態勢をとる動作を改行命令として模倣したものである。

UnixベースのOSとして再設計されたMac OS X（のちにOS Xを経てmacOSに改名）では、LFを主流として採用するようになった。

Unicodeでは改行をU+2028で、改段落をU+2029で表している。このほか、Unicodeでは垂直タブおよび改ページも改行として扱う。

 文字コード 

アラビア数字やラテン文字（いわゆる英字）以外の印字文字や、改行文字を扱う（したがって、たいていの）場合、文字コードの問題が発生する可能性がある。かつてUNIXやLinuxが拡張UNIXコード（日本語環境ではEUC-JPが多かろう）の文字コードを主に利用していたのに対し、MS-DOS・WindowsやClassic Mac OSは、Unix系とは互換性のない文字コード（日本語環境ではShift_JISの独自拡張）を主に利用していた。そのために、異なるOSを使用しているコンピュータ間でファイルを転送した場合、期待している通りにテキストが表示されない文字化けと呼ばれる現象が起きてしまうことが多かった。これらの改行コード、文字コードの違いに対する問題は、変換ソフトウェアあるいは複数の改行コードや文字コードに対応したテキストエディタなどの利用で補える。また、モダンな環境ではUnicodeの利用が一般的となっており、異なるコンピュータ間でのテキストデータ交換が容易になっているが、プレーンテキストの場合はエンコーディングの情報を含まないため、送信側と受信側の双方でエンコードとデコードに用いる文字コードを決めておく必要があり、異なる文字コードを使ってしまった場合は依然として文字化けが起きてしまうことには変わりない。

Windows NT系ではOSの内部エンコーディングはUnicodeに対応しているが、互換性の観点から、システムの言語設定（システムロケール）に応じたマルチバイト文字セットが使われている箇所がいまだに残っているため、注意が必要となる（例えばcmd.exeの出力結果をテキストファイルにリダイレクトして保存する際は、デフォルトでシステムロケールに応じたエンコーディングが使われる）。

外字フォントを利用している場合も、その文字が含まれるフォントがない場合は期待通りの表示を得られない。

 暗号技術のplaintext 

暗号化アルゴリズムへの入力を、プレーンテキスト (plaintext) と呼ぶ。こちらは英語では plain と text の間に空白が入らない。