VBA Protect Sheet en Excel — bloquea una hoja sin dejar fuera tus celdas de entrada

TL;DR — Worksheet.Protect no decide qué celdas quedan bloqueadas. Es un interruptor maestro que enciende la etiqueta Locked que ya lleva cada celda, y cada celda es Locked = True por defecto. Así que proteger una hoja sin preparación lo congela todo, incluidas las celdas que tus usuarios deben rellenar. El flujo real está invertido: primero desbloquea las celdas de entrada, luego protege la hoja. La protección también bloquea tus propias macros salvo que pases UserInterfaceOnly:=True, y ese argumento no se guarda con el archivo: lo vuelves a aplicar en cada Workbook_Open.

Sub LockDownForm()
    Dim ws As Worksheet
    Set ws = ThisWorkbook.Worksheets("Form")

    ws.Cells.Locked = True                 ' todo empieza bloqueado igualmente - se explicito
    ws.Range("C4:C12").Locked = False      ' desbloquea SOLO las celdas de entrada
    ws.Protect Password:="ac", AllowFiltering:=True   ' ahora si, acciona el interruptor maestro
End Sub

Protect es el código que hay detrás de Revisar ▸ Proteger hoja. Es una de las líneas con las que más a menudo se remata una macro que construye un formulario o un informe, y también una de las peor entendidas, porque la gente espera que bloquee «las celdas que me importan» cuando en realidad bloquea todas las celdas que llevan una etiqueta Locked, y Excel les pone esa etiqueta a todas en el instante en que nace la hoja. En cuanto ves Protect como un interruptor que aplica una decisión que las celdas ya llevan encima, en vez de como lo que toma esa decisión, cada comportamiento sorprendente encaja en su sitio.

Lo que aprenderás

• El modelo mental — Protect es un interruptor que aplica la etiqueta Locked, no la elige
• La regla que evita casi todos los fallos — desbloquea primero las celdas de entrada, luego protege
• Por qué Protect sin argumentos también bloquea filtrar, ordenar y dar formato
• Por qué una hoja protegida rompe tus propias macros, y qué hace de verdad UserInterfaceOnly:=True
• Por qué ese argumento desaparece al guardar, y dónde volver a aplicarlo
• Por qué la contraseña protege contra descuidos, no es seguridad de verdad

El modelo mental: un interruptor, no una decisión

Piensa en la protección como dos cosas distintas que la gente confunde constantemente en una sola. La decisión —«¿qué celdas puede editar un usuario?»— vive en cada celda como su propiedad Locked. La aplicación —«empieza a respetar esas decisiones ahora»— es Worksheet.Protect. El interruptor no lee tus intenciones; lee la etiqueta Locked que ya está en cada celda, y por defecto esa etiqueta es True en todas partes.

Ese único hecho explica la queja número uno sobre la protección de hojas, que es justo lo contrario de lo que esperan los principiantes. La gente supone que un ws.Protect sin preparación no bloquea nada, o que bloquea «las celdas importantes». Las bloquea todas, porque todas nacieron bloqueadas. Así que la sorpresa nunca es «mi protección no funcionó», sino «mi protección funcionó demasiado bien y ahora nadie puede escribir nada».

La regla que más importa: desbloquea primero las celdas de entrada, luego protege

Como cada celda tiene por defecto Locked = True, el patrón correcto no es «bloquear las celdas que quiero proteger». Es «desbloquear las pocas celdas que quiero dejar abiertas y luego proteger el resto». Marcas las excepciones, no los objetivos:

ws.Cells.Locked = True              ' el valor por defecto, dicho para el siguiente lector
ws.Range("C4:C12").Locked = False   ' la columna de entrada - las UNICAS celdas editables
ws.Protect Password:="ac"           ' aplicalo

Hazlo en el otro orden y te topas con el fallo clásico. Llama a ws.Protect en una hoja recién creada y luego intenta ws.Range("C4").Locked = False: la segunda línea lanza el error en tiempo de ejecución 1004, porque no puedes cambiar el estado Locked de una celda mientras la hoja está protegida. Las etiquetas Locked hay que fijarlas con la hoja desprotegida; Protect es siempre el último paso, cuando el mapa de quién-edita-qué ya está terminado. Todo el grupo cabe en una frase: Locked es el mapa, Protect enciende la aplicación.

Protect sin argumentos bloquea más de lo que crees

ws.Protect parece un simple encendido/apagado, pero acepta una larga lista de argumentos, y sus valores por defecto son restrictivos. Sin argumentos, una hoja protegida también impide a los usuarios ordenar, filtrar, dar formato e insertar o eliminar filas y columnas, incluso en celdas desbloqueadas. De aquí sale la segunda queja más habitual: «protegí la hoja y ahora los desplegables de AutoFilter están muertos».

Los argumentos son un menú de permisos. Vuelve a activar exactamente lo que la hoja necesita:

ws.Protect Password:="ac", _
    AllowFiltering:=True, _
    AllowSorting:=True, _
    AllowFormattingCells:=True

Hay un detalle que conviene conocer: AllowFiltering:=True deja que los usuarios usen los desplegables de AutoFilter que ya existen, pero no crear nuevos, así que aplica el AutoFilter antes de proteger. El criterio aquí es proteger con intención: parte de «todo está bloqueado» y enciende las interacciones concretas que esta hoja debe permitir, en vez de entregar los valores por defecto restrictivos y luego lidiar con las quejas.

La trampa que pilla a todo autor de macros: la protección bloquea tu propio código

Esta es la que convierte una macro que funciona en un error en tiempo de ejecución 1004 al día siguiente de añadir la protección. Una hoja protegida no distingue entre un usuario que escribe y tu VBA que escribe: bloquea a ambos. Así que una rutina que hacía tan feliz ws.Range("A1").Value = 42 empieza a fallar en cuanto la hoja se protege, porque ahora tu propio código se trata como un intruso.

El arreglo es el argumento UserInterfaceOnly:

ws.Protect Password:="ac", UserInterfaceOnly:=True

Con UserInterfaceOnly:=True, la hoja está protegida contra la interfaz de usuario —clics y escritura—, pero tus macros pueden seguir cambiándola con libertad, sin el baile de Unprotect/Protect alrededor de cada escritura. Es la forma más limpia de mantener una hoja bloqueada para las personas mientras tu código sigue funcionando. Pero hay trampa en la cola, y es la siguiente sección.

Por qué UserInterfaceOnly desaparece al guardar

UserInterfaceOnly:=True no se guarda con el libro. Cuando el archivo se cierra y se vuelve a abrir, la hoja regresa completamente protegida —también contra tus macros—, como si nunca hubieras pasado el argumento. La protección persiste; la parte de «pero deja pasar mi código» no. Por eso una macro funciona toda la sesión y a la mañana siguiente lanza 1004, dejando a todo el mundo perplejo.

El arreglo es volver a aplicar la protección con el argumento cada vez que se abre el libro:

' En el modulo ThisWorkbook
Private Sub Workbook_Open()
    Worksheets("Form").Protect Password:="ac", UserInterfaceOnly:=True
End Sub

Esto restablece el estado «protegida para los usuarios, abierta para el código» al cargar, sin desproteger nada ni tocar el mapa de Locked. Trátalo como un acompañante obligado de cualquier protección con UserInterfaceOnly: si dependes del argumento, dependes de Workbook_Open para restaurarlo. Consulta Workbook_Open para la mecánica del evento.

La contraseña es un quitamiedos, no una cerradura

El argumento Password parece seguridad, y vale la pena ser honesto sobre lo que no es. Las contraseñas de protección de hoja usan un cifrado débil y bien documentado; cualquier cantidad de herramientas las quita en un momento y se pueden restablecer por completo fuera de Excel. Trata la contraseña como un quitamiedos —evita que un compañero entre sin querer en tus fórmulas o sobrescriba una plantilla—, no como una caja fuerte para nada confidencial. Si los datos de verdad tienen que ser secretos, la protección de hoja es la herramienta equivocada; déjalos fuera del archivo. Y guarda la contraseña en un sitio seguro: VBA puede hacer Protect y Unprotect con una contraseña que conoces, pero no puede recuperar una que has olvidado.

Cómo te ayuda ExcelMaster

La protección es un sistema de dos pasos que se lee al revés, así que falla de formas que nunca lanzan un error en el momento en que te equivocas: dejas fuera todas las entradas porque las celdas estaban bloqueadas por defecto, entregas una hoja «de solo lectura» cuyos filtros están muertos, o tu propia macro lanza 1004 a la mañana siguiente porque UserInterfaceOnly se perdió al guardar.

ExcelMaster te deja decir lo que de verdad quieres —«bloquea esta plantilla pero deja que la gente rellene las celdas amarillas y siga usando los filtros»— y escribe los pasos de desbloquear-y-luego-proteger en el orden correcto, enciende los permisos AllowXxx que la hoja necesita, añade UserInterfaceOnly:=True con un Workbook_Open para mantenerlo vivo entre guardados, y te dice claramente que la contraseña protege contra accidentes, no contra un lector decidido. Tú conservas el libro y el código.

Preguntas frecuentes

¿Por qué no puede escribir nadie después de proteger la hoja en VBA?

Porque cada celda tiene Locked = True por defecto, así que ws.Protect bloquea la hoja entera. La protección no elige «las celdas importantes»: aplica la etiqueta Locked que ya está en todas ellas. Pon Locked = False en tu rango de entrada antes de proteger: ws.Range("C4:C12").Locked = False, y luego ws.Protect. Desbloquea las excepciones y después acciona el interruptor.

¿Cómo protejo una hoja con contraseña en VBA?

Pasa el argumento Password: ws.Protect Password:="ac". Para desproteger, pasa la misma contraseña: ws.Unprotect Password:="ac". Guarda la contraseña en tu código o en un sitio seguro: VBA no puede recuperar una olvidada. Y trátala como una barrera contra descuidos, no como seguridad: las contraseñas de protección de hoja se quitan en un momento y nunca deben ser la garantía de que datos confidenciales queden ocultos.

¿Por qué mi macro da error 1004 en una hoja protegida?

Una hoja protegida bloquea tus escrituras de VBA igual que bloquea a un usuario. Protege con UserInterfaceOnly:=True para que la hoja siga bloqueada para las personas mientras tu código puede seguir cambiándola. Ten en cuenta que este argumento no se guarda con el libro, así que vuelve a aplicarlo en un evento Workbook_Open —Worksheets("Form").Protect Password:="ac", UserInterfaceOnly:=True— o la macro fallará después de reabrir el archivo.

¿Cómo mantengo el filtrado y la ordenación en una hoja protegida?

Por defecto, Protect los bloquea. Vuelve a activarlos con los argumentos: ws.Protect AllowFiltering:=True, AllowSorting:=True. AllowFiltering:=True deja que los usuarios manejen los desplegables de AutoFilter que ya existen, pero no crear nuevos, así que aplica el AutoFilter antes de proteger. Añade AllowFormattingCells:=True y los demás argumentos AllowXxx para cualquier interacción que la hoja todavía necesite.

¿Cuál es la diferencia entre proteger una hoja y proteger el libro?

Worksheet.Protect impide que se editen las celdas de una hoja. Workbook.Protect bloquea la estructura del libro —impide añadir, eliminar, renombrar, mover u ocultar hojas— y no hace nada al contenido de las celdas. Resuelven problemas distintos: la protección de hoja cuida la introducción de datos, la protección de libro cuida la disposición de las pestañas. A menudo usas ambas en una plantilla terminada.

Probado en

Probado en: Excel 365 (Windows 11), VBA 7.1 — última verificación el 11/09/2026.

Guías relacionadas: VBA Unprotect · VBA Lock Cells · VBA Workbook_Open · VBA AutoFilter · VBA Range