Known unknowns are what make an estimate a range. Unknown unknowns are what will make it completely useless.
For the known unknowns, make them knowns. Put together best and worst case scenarios. Weight your estimate towards the worst-case scenarios.
Unknown unknowns, well... the trick is to turn as many of them as possible into known unknowns. Skim through the code you're extending, or sketch yourself a diagram of what you're building from scratch. Check your assumptions about APIs or available data. If it's a small project, have an idea as close as possible to exactly what lines you'll have to write/change to accomplish your task. If it's a very large project, write the tiniest possible proof of concept of the riskiest portion to validate your assumptions before giving an estimate.
Make yourself a checklist of steps to complete your task. Break those down into at least three sub-steps for each step. Then break those steps down further until you're down to tasks that will take no more than two hours apiece to complete.
Don't forget to include time for writing automated tests; for manual testing; and for fixing things that don't work the way you intended the first time around.
If you're being asked for a turnaround time estimate rather than a person-hours estimate, don't forget to include time spent waiting for answers or verification from other stakeholders. If you're integrating with a third-party service, include time for back-and-forths with tech support, and for implementing workarounds because their platform doesn't actually do what it says it does the way it says it does, and (if they're a new vendor) for contract negotiations to drag on.
Then multiply your estimate by two.
Examples:
If there is UI involved, count or estimate the screens and their complexity (# of controls, plus a factor for what your gut says the complexity of each control is)
If you have to process xml, json or something like it, count the number of different tags in the file. Again, add or multiply by what your gut/experience tells you the complexity of the structure or what you have to do with it is.
Similarly, for a database, guess/count tables, fields and foreign keys.
If there are N stakeholders, multiply your estimate by f(N) for some strictly increasing f (they won't accept f(x) = x, but square root works fine). if they complain, saying they will not disagree, ask them to appoint a single stakeholder so that the others don't need to waste time saying what that single stakeholder would say, anyways.