因为在OpenGL2.0之前，OpenGL基本的设计是作为固定功能状态机，所以要修改OpenGL的唯一方法是对它定义扩展。这样，在各种OpenGL实现中，要通过扩展的形式来暴露新的功能，从而有了大量可用的扩展。OpenGL有一个定义良好的扩展机制，并且硬件制造商可以*地定义并实现新硬件功能的特征。但由于只有OpenGL实现者才能实现才能实现扩展，因此就无法预先为应用程序扩展此OpenGL功能，直到OpenGL提供商提供了扩展的实现。
到目前为止，已经有超过400个OpenGL扩展了。只被一家制造商支持的扩展是通过用一个唯一标识该制造商的短的前缀来标识的（比如，SGI就是由Silicon Graphics, Inc.开发的扩展）。超过1家制造商所支持的扩展在扩展名中用前缀EXT来表示。而彻底被ARB组织评审的扩展在扩展名中用ARB前缀标出，以指示它们具有作为一个揭露某个功能的推荐方法的一个特殊状态。达成ARB标签的扩展将作为被添加到标准OpenGL的候选。发表的OpenGL扩展的详细说明可以在www.opengl.org/registry/中查询到。
被一个特定的OpenGL实现所支持的扩展可以通过调用OpenGL函数glGetStringi来确定，参数传GL_EXTENSIONS。返回的字符串包含了被此实现所支持的扩展名。一些制作商当前支持了超过100个单独的OpenGL扩展（比如Apple在Mac OS X Snow Leopard上使用GeForce 9400 GPU就支持了120多个独立的扩展）。这对于一个应用程序要设法确定所需的扩展是否在现有的各种实现上被支持，并且如果不被支持该做什么，而显得有些令人怯步。扩展的不断增长对于OpenGL开发根本上是一个积极的因素，但在某种意义上，它已经成了其自身成功的受害者。它允许硬件制造商轻而易举地暴露新的特征，但它给应用开发者带来了一系列令人眼花缭乱的非标准选项。就像任何一个标准体系，ARB对从扩展状态的功能提升到OpenGL标准非常谨慎。
在OpenGL的版本2.0之前，图形硬件的底层可编程性没有被暴露。OpenGL的原始设计者Mark Segal和Kurt Akeley陈述到：“做此决定的一个理由是，对于性能的原因，图形硬件硬件通常被设计为以一种特定的次序提供某些操作；用任意的算法去取代这些操作通常是不可实行的。”这话在当时1994年基本上是正确的（在当时甚至已经有了可编程的图形架构）。但今天，正被生产的所有图形硬件都是可编程的。因为OpenGL扩展的不断繁殖，并且又需要支持微软的DirectX API，硬件制造商没有选择，只能设计可编程的图形架构。