The first thing to do is check to see if you're being asked for an estimate or a commitment. Especially in software development, these words are often misused.
An estimate should be a range with an indication of your confidence in the values. For example, you might estimate a project as 25% confidence of accomplishment in 5 days, 50% in 8 days, 90% in 12 days. If you track your estimates over time, the midpoint of your range should be under your actual time about the same amount it is over.
A commitment is an agreement you will have the project complete in N days.
In my team, we use estimates (ranges) with each other. But product management gets a commitment number, even if they want to call it an estimate.
Once you know whether you're being asked for a real estimate or a number to be used as a commitment, decompose the project as a whole into discrete tasks. You want a list of the work that needs to be done, with each task being no more than 3 days in length. Ideally, half to 1 day's work, although it takes a lot of practice to be able to decompose a project into pieces that size without doing a lot of design up front.
Include tasks for research and prototyping if you don't already know how to do something.
When you're done breaking the project down, add up your total and there's a number.
One of the advantages of breaking down this way is that you'll get early warning if a project starts to go off the rails with tasks running long, and you can then make adjustments accordingly.