Comillas simples vs dobles en programación: guía por lenguaje

Copiaste una consulta que funcionaba en tu cabeza, la pegaste en el código y la base de datos devolvió un error de sintaxis en la línea 1. O peor: no devolvió error, pero borró la tabla equivocada. Casi siempre el culpable es el mismo, y es ridículamente pequeño: una comilla. Elegiste comillas simples donde tocaban dobles, o al revés, y el intérprete te entendió literalmente, que es lo único que sabe hacer. Las comillas simples no son un capricho de estilo que resuelvas con "elige una y sé consistente". En algunos lenguajes son intercambiables y en otros significan cosas radicalmente distintas, y confundirlas es el origen de bugs que van desde un echo que imprime $nombre en vez del nombre hasta la mitad de las inyecciones SQL del mundo.

Llevo más de veinte años escribiendo código en PHP, JavaScript, Python, SQL y shell, saltando entre ellos varias veces al día. La regla que uso no es "comillas simples buenas, dobles malas". Es saber, en cada lenguaje, qué hace exactamente cada tipo de comilla. Eso es lo que voy a dejar aquí, lenguaje por lenguaje, con los casos límite que la documentación menciona de pasada y los errores que vas a cometer si no los conoces.

Comillas simples frente a dobles: la diferencia no es estética

Hay dos ejes que decidirán, en cada lenguaje, si la elección importa o no.

El primero es la interpolación: ¿el lenguaje mira dentro de la cadena para sustituir variables y procesar secuencias de escape, o la trata como texto muerto? El segundo es el rol sintáctico: ¿la comilla delimita un valor de texto o delimita un nombre de tabla, columna o clave? Cuando cambia el eje, cambia todo.

Si te quedas con una idea de todo el artículo, que sea esta: la pregunta correcta nunca es "¿cuáles quedan mejor?", sino "¿qué hace este lenguaje con cada una?". A partir de ahí, cada sección responde esa pregunta.

PHP: las dobles interpolan, las simples no

Aquí es donde la diferencia es más tangible y donde más gente tropieza. En PHP, la cadena entre comillas dobles se procesa; la cadena entre comillas simples se guarda casi tal cual.

$nombre = 'Joan';

echo "Hola, $nombre";   // Hola, Joan
echo 'Hola, $nombre';   // Hola, $nombre

Las dobles buscan variables ($nombre, {$objeto->prop}, $array['clave']) y las sustituyen. También procesan secuencias de escape: \n es un salto de línea real, \t un tabulador, \\ una barra, \" una comilla doble literal, además de \r, \v, \f, \e, los códigos octales, \x41 en hexadecimal y \u{1F600} en Unicode. Las comillas simples solo reconocen dos secuencias: \' para una comilla simple literal y \\ para una barra. Todo lo demás es texto crudo.

echo "Línea 1\nLínea 2";   // dos líneas
echo 'Línea 1\nLínea 2';   // Línea 1\nLínea 2  (la n y la barra, literales)

El error clásico: escribir una plantilla de correo o una consulta con comillas simples y meter \n esperando saltos de línea. No los vas a ver. Y el inverso, igual de común: usar comillas dobles en una cadena que lleva un signo de dólar seguido de algo que sí parece una variable, una contraseña, una expresión regular, una plantilla, y que PHP te la sustituya por su valor, o por nada.

Conviene entender cuándo el dólar interpola de verdad. En PHP un nombre de variable empieza por letra o por guion bajo, nunca por un dígito:

$importe = 50;

echo "Cuesta $importe €";   // Cuesta 50 €        <- la doble interpola
echo 'Cuesta $importe €';   // Cuesta $importe €  <- la simple, no

// Y el caso que casi todos los tutoriales cuentan mal:
echo "Cuesta $50";          // Cuesta $50   <- $50 no es un nombre de variable válido
echo 'Cuesta $50';          // Cuesta $50   <- exactamente lo mismo

Las dos últimas líneas imprimen lo mismo. PHP no busca ninguna variable $50 ni lanza ningún error: un identificador no puede empezar por un dígito, así que el dólar se queda literal. El peligro no está en $50, está en $total y en $_precio. Si el dólar va seguido de una letra o de un guion bajo, las comillas dobles se lo comen.

Sobre el rendimiento hay un mito que conviene enterrar: no, las comillas simples no son más rápidas. El motor busca las variables al compilar, no en cada ejecución, y con opcache ese trabajo se hace una sola vez. En una cadena constante, sin variables, no hay diferencia medible en tiempo de ejecución, ni siquiera en un bucle de millones de vueltas. La razón para elegir simples es semántica: si la cadena no tiene que interpolar nada, decláralo con comillas simples y le comunicas a quien lea el código, y a ti mismo dentro de seis meses, que ahí no hay variables escondidas. Es documentación gratis.

Mi regla en PHP: comillas simples por defecto; comillas dobles solo cuando interpolo. Y para interpolación compleja, sprintf() o la sintaxis de llaves {$var}, que es inequívoca.

JavaScript: simples y dobles son equivalentes; para interpolar, acento grave

En JavaScript, 'texto' y "texto" producen exactamente el mismo string. No hay diferencia funcional, de rendimiento ni de comportamiento. Elegir entre una y otra es una decisión puramente estética, y por eso no debería decidirla tu opinión: debería decidirla el linter.

La interpolación en JavaScript no vive en las comillas rectas. Vive en las plantillas literales, que se delimitan con acento grave (`) y permiten incrustar expresiones con ${...} y escribir cadenas de varias líneas sin \n:

const nombre = 'Joan';

const saludo = `Hola, ${nombre}`;        // Hola, Joan
const total  = `Suma: ${2 + 2}`;         // Suma: 4
const bloque = `Primera línea
Segunda línea`;                          // salto real, sin \n

Antes de las plantillas literales se concatenaba con +, y todavía se ve mucho código así. Hoy no hay razón para escribir 'Hola, ' + nombre + '. Tienes ' + n + ' mensajes' cuando la plantilla lo dice de un vistazo. Reserva el acento grave para cuando de verdad interpolas o necesitas varias líneas; para un string constante, una plantilla literal sin ${} es ruido.

¿Simples o dobles para el resto? Deja que lo imponga la herramienta. Prettier usa comillas dobles por defecto; muchas configuraciones de ESLint prefieren simples. Cualquiera de las dos está bien mientras sea automática y uniforme en todo el repositorio. Discutirlo en una revisión de código es malgastar el tiempo de dos personas: configura la regla, activa el formateo al guardar y no vuelvas a pensarlo. La única sutileza real es evitar el escape innecesario: si el texto lleva un apóstrofo, delimítalo con dobles ("L'Hospitalet") en vez de escaparlo ('L\'Hospitalet'). La mayoría de linters con la opción avoid-escape ya lo hacen por ti.

Python: PEP 8 no elige por ti

Python es el caso más limpio de todos: 'texto' y "texto" son idénticos, sin ninguna diferencia. Y a diferencia de lo que mucha gente cree, la guía de estilo oficial no toma partido. PEP 8 lo dice con todas las letras: las cadenas con comillas simples y las de comillas dobles son lo mismo, esta PEP no hace ninguna recomendación, elige una regla y respétala.

La única indicación concreta que da PEP 8 es práctica: cuando una cadena contiene un tipo de comilla, usa el otro para delimitarla y así evitas los escapes y mejoras la legibilidad.

frase = "No es lo que él llamaría 'legible'"   # sin escapes
frase = 'No es lo que él llamaría \'legible\''  # peor

La interpolación moderna en Python son las f-strings, que anteponen una f a la comilla, simple o doble, da igual, y evalúan expresiones dentro de llaves:

nombre = "Joan"
saludo = f"Hola, {nombre}"        # Hola, Joan

Y una recomendación que sí es explícita: para las cadenas de triple comilla (docstrings), PEP 8 pide usar comillas dobles """...""", por consistencia con la convención de docstrings de PEP 257. Ese es el único punto donde Python te dice cuál. En el resto, la respuesta honesta es que da igual: elige, configúralo en tu formateador (Black impone dobles) y sigue con tu vida.

SQL: las comillas simples delimitan cadenas, las dobles y los backticks delimitan identificadores

Aquí la cosa deja de ser estética y se vuelve peligrosa. En SQL, los dos tipos de comilla no son variantes del mismo concepto: son dos sintaxis distintas para dos cosas distintas.

• Las comillas simples delimitan un literal de cadena: un valor de texto, un dato.
• Las comillas dobles delimitan un identificador: el nombre de una tabla, una columna, un alias.

-- Correcto: 'activo' es un valor; "estado" es el nombre de la columna
SELECT * FROM usuarios WHERE "estado" = 'activo';

-- En SQL estándar y en PostgreSQL: busca una columna llamada "activo" y falla.
-- En MySQL con la configuración por defecto (sin ANSI_QUOTES): NO falla,
-- porque trata "activo" como una cadena. Que funcione no significa que esté bien.
SELECT * FROM usuarios WHERE estado = "activo";

Ese segundo caso es el malentendido que arrastra media internet. En un lenguaje donde las comillas son intercambiables, "activo" es una cadena. En SQL estándar, "activo" es el nombre de un identificador, y si no existe ninguno así, la consulta falla.

Y aquí llega la trampa específica de MySQL, que es el motor más extendido y el que rompe la intuición: por defecto, MySQL no usa comillas dobles para identificadores, usa backticks (`). Peor todavía: sin el modo ANSI_QUOTES activado, MySQL acepta las comillas dobles como delimitador de cadena, igual que las simples. Así que un desarrollador aprende en MySQL que "activo" es una cadena, se lleva esa costumbre a PostgreSQL o a un motor en modo estándar, y su código deja de funcionar sin que entienda por qué.

-- MySQL: identificadores con backtick; el guion lo obliga
SELECT `nombre-completo` FROM `mi-tabla` WHERE `estado` = 'activo';

La regla que no falla en ningún motor: valores entre comillas simples, siempre. Para los nombres de tablas y columnas, backticks en MySQL y comillas dobles en PostgreSQL, SQLite y el estándar. Si escribes SQL portable, no delimites identificadores salvo que sea imprescindible (nombres con espacios, guiones o palabras reservadas) y, cuando lo hagas, respeta el dialecto del motor.

Cómo escapar una comilla dentro de una cadena SQL y por qué a mano nunca funciona

Si los valores van entre comillas simples, ¿qué pasa cuando el valor contiene una comilla simple? El caso de manual: un apellido como O'Brien.

-- Rompe: la comilla de O'Brien cierra la cadena antes de tiempo
SELECT * FROM clientes WHERE apellido = 'O'Brien';

El SQL estándar tiene una regla clara para escapar una comilla simple dentro de una cadena: se duplica. Dos comillas simples seguidas dentro de la cadena representan una comilla literal.

-- Correcto: '' dentro de la cadena es una comilla simple literal
SELECT * FROM clientes WHERE apellido = 'O''Brien';

Fíjate en que no es una comilla doble: son dos comillas simples pegadas. Es el escape estándar, y funciona. Ahora viene lo importante, y es donde este artículo se separa de cualquier tutorial que te diga "recuerda duplicar las comillas": escapar a mano no es una defensa contra la inyección SQL. Es una tirita que se cae al primer caso raro.

Duplicar comillas cubre las comillas. Pero la entrada de un atacante no llega solo con comillas: llega con codificaciones alternativas, con juegos de caracteres multibyte donde un byte se combina con tu comilla de escape para formar otro carácter, con comentarios --, con la barra invertida según el motor. Cada motor tiene sus reglas, cada charset sus fugas, y en cuanto construyes una consulta pegando trozos de texto, por muy bien que creas escapar, has abierto la puerta. La postura oficial de OWASP sobre escapar la entrada es tajante: está fuertemente desaconsejado como defensa primaria y no garantiza prevenir todas las inyecciones. No lo digo yo por manía; lo dice la guía de referencia del sector.

La conclusión honesta: si te encuentras escapando comillas a mano para meter un valor en una consulta, párate. Estás resolviendo el problema equivocado. La solución no es escapar mejor. Es no concatenar.

La solución real a la inyección SQL: consultas preparadas con parámetros vinculados

La defensa primaria que recomienda OWASP es una sola: consultas preparadas con parámetros vinculados (prepared statements). La idea es que dejas de construir la consulta como texto. Envías al motor la estructura de la consulta con marcadores donde van los valores, y luego le pasas los valores por separado. El motor nunca interpreta esos valores como parte de la sintaxis SQL: son datos, y solo datos. La comilla dentro del valor deja de ser un problema porque ya no vive en el mismo canal que el código.

Así se ve en PHP con PDO:

// Vulnerable: la entrada se concatena y puede romper la sintaxis
$sql = "SELECT * FROM usuarios WHERE nombre = '" . $_GET['nombre'] . "'";

// Correcto: el valor viaja aparte, nunca se interpreta como SQL
$stmt = $pdo->prepare('SELECT * FROM usuarios WHERE nombre = ?');
$stmt->execute([$_GET['nombre']]);
$fila = $stmt->fetch();

Con la versión preparada, si alguien envía como nombre ' OR '1'='1, no pasa nada: el motor busca literalmente un usuario cuyo nombre sea la cadena ' OR '1'='1, no encuentra ninguno y devuelve cero filas. El ataque clásico se desactiva solo, sin que tú escapes nada.

En Python con el módulo sqlite3, mismo principio (usa marcadores ?, nunca formateo de cadenas):

# Correcto: parámetros vinculados, no f-strings en la consulta
cur.execute("SELECT * FROM usuarios WHERE nombre = ?", (nombre,))

# PROHIBIDO: esto es exactamente la inyección
cur.execute(f"SELECT * FROM usuarios WHERE nombre = '{nombre}'")

Un límite que conviene conocer, porque a todo el mundo le muerde una vez: los parámetros vinculados sirven para valores, no para identificadores. No puedes parametrizar el nombre de una tabla o de una columna ni la dirección de un ORDER BY. Si necesitas que sean dinámicos, no los pegas: los validas contra una lista blanca de valores permitidos y solo entonces los insertas en la consulta. Cualquier otra cosa reabre el agujero que las consultas preparadas cerraban. Este es exactamente el tipo de detalle que separa un desarrollo web a medida de una plantilla parcheada: no está en que compile, está en que no se rompa cuando alguien empuja.

Shell (Bash): las simples no expanden nada, las dobles sí

En la shell la distinción vuelve a ser funcional, y de las que más quebraderos de cabeza dan en scripts de despliegue. Las comillas simples preservan el valor literal de cada carácter que encierran: no expanden variables, ni comandos, ni el *, ni nada. Las comillas dobles preservan casi todo, con tres excepciones que sí se interpretan: el signo de dólar ($), el acento grave y la barra invertida.

nombre="Joan"

echo "Hola $nombre"    # Hola Joan     (expande la variable)
echo 'Hola $nombre'    # Hola $nombre  (literal, no expande)
echo "Hoy es $(date)"  # ejecuta date y sustituye
echo 'Hoy es $(date)'  # Hoy es $(date)  (literal)

La consecuencia práctica más importante: cuando pasas una contraseña, una expresión regular o cualquier cadena con $, ` o \ a un comando, y no quieres que la shell la toque, usa comillas simples. Y cuando de verdad necesitas que una variable se expanda, usa dobles y entrecomilla siempre la variable, "$archivo", no $archivo, porque sin comillas un nombre de fichero con un espacio se parte en dos argumentos y el script hace algo distinto de lo que crees. Ese único descuido, rm $archivo en vez de rm "$archivo", ha borrado más cosas de la cuenta.

¿Y si necesito una comilla simple dentro de comillas simples? No se puede escapar dentro: hay que cerrar, poner la comilla escapada y reabrir, con el idioma '\''. Es feo, pero es la forma correcta: echo 'O'\''Brien'.

JSON y YAML: en JSON solo existen las comillas dobles

En JSON no hay debate posible: solo las comillas dobles son válidas, tanto para las claves como para los valores de tipo cadena. Un string de JSON se define como una secuencia de caracteres Unicode entre comillas dobles. Las comillas simples no son un estilo alternativo: son un error de sintaxis que hará fallar cualquier parser conforme.

{ "nombre": "Joan", "activo": true }

{ 'nombre': 'Joan' }   // INVÁLIDO: JSON no acepta comillas simples

Esto es la causa número uno de "mi JSON no parsea" cuando alguien escribe a mano un cuerpo de petición o un fichero de configuración copiando el hábito de JavaScript, donde las simples sí valen. En un objeto JavaScript las comillas simples son correctas; en cuanto ese objeto se serializa a JSON o lo lees con JSON.parse(), dejan de serlo. Son dos formatos distintos que se parecen demasiado.

YAML es más permisivo y por eso engaña. Acepta cadenas sin comillas, con comillas simples y con comillas dobles, y las tres se comportan distinto. Las comillas dobles procesan secuencias de escape (\n es un salto de línea) y las simples no (dentro de comillas simples, una comilla literal se escribe duplicándola, ''). El caso donde YAML te muerde son los valores que parecen otra cosa: no, yes, on, off se interpretan como booleanos, y una versión como 1.20 puede quedarse en 1.2 si es un número. Si quieres que algo sea texto y solo texto, entrecomíllalo. Y como JSON es un subconjunto de YAML, si dudas, escribe JSON válido: siempre es YAML válido.

CSV y Excel: cuándo la comilla delimita y cuándo se duplica

En CSV la comilla que manda es la doble, y su papel es acotar campos que contienen el propio separador. Si un campo lleva una coma, un salto de línea o una comilla, se envuelve entre comillas dobles. Y cuando dentro de ese campo hay una comilla doble literal, se duplica, igual que las simples en SQL.

nombre,nota
"Medina, Joan","Dijo ""hola"" y se fue"
Ana,Sin comas

Ese "" de dentro no son dos campos vacíos: es una comilla doble literal dentro del texto Dijo "hola" y se fue. Es la regla del formato CSV estándar, y saltársela es la razón por la que tantos exports "se descuadran" al abrirlos: un nombre con una coma sin entrecomillar empuja todo a la columna siguiente.

Excel añade su propia trampa, que no es de comillas sino de comportamiento. Al abrir un CSV, Excel reinterpreta los valores: un código como 007 pierde el cero inicial, un 3-4 se convierte en fecha, un número largo se pasa a notación científica. Las comillas del fichero no lo evitan, porque Excel las consume al importar. Si necesitas preservar el texto exacto, no abras el CSV de doble clic: impórtalo con el asistente marcando la columna como texto, o entrega directamente un .xlsx donde el tipo de cada celda va declarado. Cuando construyo exports para clientes, esto es la mitad del trabajo real; lo cuento con más detalle al hablar de automatizar facturas y albaranes con IA.

El enemigo silencioso: las comillas tipográficas que rompen el código

Y aquí está el que se lleva más horas de depuración por unidad de estupidez: las comillas tipográficas, también llamadas comillas curvas o inteligentes. Son las que un procesador de textos sustituye automáticamente por "elegancia": ' recta se convierte en ' o ' (curvas), y " recta en " o ". A la vista son casi idénticas. Para el compilador son caracteres Unicode completamente distintos (U+2018, U+2019, U+201C, U+201D) que no delimitan absolutamente nada.

El síntoma es inconfundible una vez lo conoces: copias un fragmento de un PDF, de un correo, de un documento de Word, de una web o de una app de notas, lo pegas, y el intérprete escupe un error de sintaxis en una línea que a ojo está perfecta. Lo relees diez veces sin ver nada raro, porque tus ojos leen "comilla" y el parser lee "carácter de puntuación tipográfico que no es una comilla".

$saludo = 'Hola';   // comillas rectas: correcto
$saludo = 'Hola';   // comillas curvas: error de parseo, aunque se vean casi iguales

El origen casi siempre es la autocorrección: Word, Google Docs, las Notas de macOS y muchos gestores de contenido convierten las comillas rectas en curvas mientras escribes, sin avisar. La defensa es doble. Primero, no escribas código en un procesador de textos; usa un editor de código de verdad, que nunca hace esa sustitución. Segundo, cuando pegues algo de fuera y falle de manera inexplicable, sospecha de las comillas antes que de tu lógica: borra las comillas del fragmento y reescríbelas a mano en el editor. Si el error desaparece, ahí estaba. Muchos editores tienen un ajuste para hacer visibles los caracteres no ASCII, y activarlo te ahorra el resto de tu vida buscando este fantasma.

Regla rápida por lenguaje

El resumen que puedes pegar encima del monitor:

• PHP: comillas simples por defecto; dobles solo cuando interpolas variables o necesitas escapes como \n.
• JavaScript: simples o dobles, da igual; que lo decida el linter. Para interpolar, acento grave y ${...}.
• Python: simples o dobles, da igual; PEP 8 no elige. Dobles para los docstrings de triple comilla. Para interpolar, f-strings.
• SQL: comillas simples para valores, siempre. Identificadores con backticks en MySQL y comillas dobles en el estándar.
• Inyección: nunca concatenes ni escapes a mano; usa consultas preparadas con parámetros vinculados. Identificadores dinámicos, por lista blanca.
• Shell (Bash): simples para texto literal; dobles cuando quieras expandir variables, y entrecomilla siempre la variable.
• JSON: solo comillas dobles. Las simples son un error.
• YAML: entrecomilla los valores que puedan confundirse con booleanos o números.
• CSV: comillas dobles para acotar; una comilla literal se duplica.
• Comillas tipográficas: no escribas código en Word; si algo falla sin motivo, sospecha de las comillas curvas.

La comilla parece el detalle más insignificante del código. Es justo por eso por lo que se cobra tantas horas: nadie la mira. Si tienes entre manos un proyecto donde estos detalles se están acumulando en forma de bugs raros, hablemos de tu proyecto y lo miramos con calma.