ミップマップの個々のビットマップ画像は、メインのテクスチャのあるバージョンだが、詳細さのレベルがある程度低減されている。視点が近く、その画像を詳細にレンダリングする場合はメインのテクスチャを使うが、視点がある程度遠く見た目が小さくなる場合は適当なミップマップ画像に切り替えて（あるいは、トリリニアフィルタリングが有効であれば、適当なミップマップ2つから内挿で求める場合もある）レンダリングする。生成すべきテクスチャのピクセル数（テクセル）を削減できるため、レンダリングは高速化できる。ミップマップ画像は事前に効果的にアンチエイリアスされているため、ある意味ではレンダリングの仕事を事前に一部済ませているようなもので、より自然な見た目を生成できる。拡大・縮小もミップマップがあると、より効率的にできる。
例えば、256×256のテクスチャがあるとする。これに付随するミップマップ画像は8個あり、メインの画像から次々に4分の1の面積に縮小したものとする。つまり、それぞれの大きさは 128×128、64×64、32×32、16×16、8×8、4×4、2×2、1×1 となる。このテクスチャを 40×40 ピクセルの領域としてレンダリングする必要が生じた場合、32×32のミップマップ画像を拡大して使うか（トリリニアフィルタリングしない場合）、64×64と32×32のミップマップ画像から内挿して使う（トリリニアフィルタリングする場合）。これらのテクスチャを生成する最も単純な方法として逐次平均化があるが、（信号処理やフーリエ変換に基づいた）もっと洗練されたアルゴリズムを使うこともできる。
ミップマップを準備することで増加する格納領域は元のテクスチャの3分の1である。これは、1/4 + 1/16 + 1/64 + 1/256 + ⋯ が1/3に収束するためである。RGB画像を3つの別々の平面として格納する場合、全ミップマップは元の画像の各次元の倍の大きさの矩形領域にきちんと収まる。このことから "multum in parvo" という成句が使われることになった。
多くの場合、テクスチャフィルタリングは全ての方向で一様ではなく（つまり等方的ではなく異方的である）、妥協的解像度を使う。高い解像度のものを使うとキャッシュコヒーレンシが保たれず、一方向でエイリアシングが増大する。しかし画像はよりクリアになる。低い解像度のものを使うとキャッシュコヒーレンシは良くなるが、画像はぶれたようになり、識別しにくくなる。
この問題に対処するため、一様でないミップマップ（リップマップとも）を使うこともある。元のテクスチャが16×16なら、リップマップは 16×8、16×4、16×2、16×1、8×16、8×8、8×4、8×2、8×1、4×16、4×8、4×4、4×2、4×1、2×16、2×8、2×4、2×2、2×1、1×16、1×8、1×4、1×2、1×1 を用意する。この手法の問題は、リップマップには元のテクスチャの4倍の記憶領域が必要となる点で、このためリップマップはあまり使われない。
メモリ必要量を減らし、同時に使える解像度のレベルを増やすためにエリア総和テーブルが考案された。しかしこの手法はキャッシュの効率が悪い。また、部分和を格納するデータ型はテクスチャを格納する際のワード長よりも長いものが必要である。このため、今のところエリア総和テーブルをハードウェアで実装した例はない。
今日よく使われる妥協策は、異方性ミップマッピングと呼ばれている。この場合異方性フィルタを必要とし、より高解像度のミップマップを使う。そして、画像の向きに応じて、ある方向ではいくつかのテクセルの平均をとる。キャッシュ効率という意味ではよくないが、画像の見た目は劇的に改善される。
