I’m working on styling a contact form and need help changing the placeholder text color. The placeholders like “Your Name” and “Email Address” appear in white, but I can’t figure out what CSS is controlling this color.
When I use browser dev tools to inspect the form fields, I can see the styling for the input elements but the placeholder color properties don’t show up in the computed styles or regular styles tab.
When I try changing the color property from #ffffff to something else (even with !important), it only affects some placeholders like dropdown options but not the main text input placeholders.
What CSS selectors should I be looking for to target these placeholder elements specifically? Any suggestions on how to identify what’s controlling the placeholder styling would be really helpful.
Hit this same issue yesterday! HubSpot loads their styles really late, so they override yours. I fixed it by using html .contact-form input::placeholder - the html prefix bumps up specificity enough to beat their selectors without having to dig through their CSS classes.
The placeholder color issue happens because HubSpot injects inline styles after the page loads. I ran into this on a corporate site where my placeholders kept reverting to default colors even though my CSS looked right. Here’s what worked: target the HubSpot form wrapper with .hs-form-private input::placeholder and load it via JavaScript after HubSpot’s script runs. The trick is that HubSpot applies styles programmatically, not just through CSS files. Check the Elements panel after the form loads - you’ll see inline style attributes that weren’t there before. Put your placeholder styles inside a setTimeout function or use window.onload so they apply after HubSpot’s styling routine finishes.
This is a CSS specificity issue with HubSpot’s generated classes. I ran into the exact same thing last month on a client’s landing pages. HubSpot wraps forms in containers like .hs-form-private that have higher specificity than your regular selectors. Instead of just .contact-form, try .hs-form-private .contact-form input[type=text]::placeholder or similar combinations. What really saved me was adding the CSS directly through HubSpot’s custom CSS section in the form editor instead of my site’s stylesheet. This makes sure your placeholder styles load in the right order with HubSpot’s form CSS. Also check if there’s a .hs-form-field wrapper around your inputs - you’ll often need to include that class in your selector chain for the styles to actually work.
CSS works, but HubSpot’s form styling quirks are a pain. Dealt with this exact problem last year when marketing kept wanting custom tweaks.
HubSpot loads styles dynamically and overrides your CSS even with !important. Every time they update their embed code, you’re back to adjusting selectors.
I automated the whole thing instead. Built a workflow that intercepts submissions, applies styling rules, and handles CSS injection automatically. No more dev tools hunting or pseudo-element headaches.
The automation watches for form updates and reapplies styles when HubSpot changes things. Browser fallbacks are automatic too.
Saved us 5-6 hours monthly on styling fixes. Now when marketing wants different placeholder colors, it’s instant instead of manual CSS debugging.
Latenode makes this workflow setup pretty simple. You can build the monitoring and styling automation without complex code.
This is a common HubSpot forms issue. Placeholder styling uses pseudo-element selectors that don’t show up in regular computed styles. You need to target the ::placeholder pseudo-element directly in your CSS. Try adding these rules to your existing styles: .contact-form input[type=text]::placeholder, .contact-form input[type=email]::placeholder, .contact-form textarea::placeholder { color: #your-desired-color !important; opacity: 1; } The opacity: 1 part matters because browsers usually apply default opacity to placeholders. Modern browsers support ::placeholder just fine, but you might need -webkit-input-placeholder and -moz-placeholder prefixes for older ones. If it’s still not working, HubSpot might be loading styles after yours. Fix this by making your selectors more specific - add the form’s container ID or class.
HubSpot forms are a pain - they inject their own CSS classes that override your custom styles. I’ve dealt with this headache on multiple client sites. HubSpot generates unique class names that aren’t obvious at first glance. Skip the dev tools and inspect the actual HTML source instead. You’ll find classes like .hs-input or .hs-fieldtype-text that get added automatically. Try using .hs-form .hs-input::placeholder instead of targeting your custom form class. Here’s the real kicker: HubSpot often loads their default styles after your CSS runs, so timing screws you over. I fixed this by putting my placeholder styles in a separate CSS file that loads after the HubSpot embed script, or using more specific selectors to beat HubSpot’s CSS specificity. Check your network tab to see which CSS files load first.
I’ve been fighting HubSpot forms for years and the CSS approach is a total nightmare.
Every HubSpot update breaks your selectors. You’re constantly chasing moving targets with specificity wars and pseudo-element prefixes.
So I built an automation that actually works. It watches HubSpot forms, catches their dynamic class changes, and auto-injects the right CSS with proper specificity. No more hunting down selectors manually.
It also handles cross-browser compatibility and updates styles when HubSpot changes their form rendering.
This has saved me tons of hours debugging placeholder colors across client sites. I set the colors once and the automation deals with all of HubSpot’s quirks.
Latenode makes this kind of form monitoring and CSS injection super easy to set up.